mlockall (again)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

mlockall (again)

Maxim Krikun
Hi all

I have read the discussions on mlockall() on this list,
and i see why reducing global mlockall() to mlock() on
specific pages is a difficult problem.

But still, could mlockall() be made optional for clients
that wish to lock their memory themselves (for example
by passing  JackNoMlockall option to jack_client_new) ?

As far as i can see even if the client does mlock() wrong
and there's eventually a page fault inside it's process callback,
in the worst case only that client will be kicked out,
but jackd will continue to run.

So why not allow those who are aware of the risks of
no-mlockall() to do their stuff as they like?

More precisely, my problem is the following: i use mmap() to
simplify access to large wave file (exceeding phisycal memory).
To have jack output in the same program, i have three options:
- stop using mmap
- fork all jack-related stuff to a separate process
- require jackd with --no-mlock.
Neither option seems attractive, but what else?



regards,
Maxim


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

Lee Revell
On Mon, 2006-06-12 at 13:55 +0200, Maxim Krikun wrote:

> Hi all
>
> I have read the discussions on mlockall() on this list,
> and i see why reducing global mlockall() to mlock() on
> specific pages is a difficult problem.
>
> But still, could mlockall() be made optional for clients
> that wish to lock their memory themselves (for example
> by passing  JackNoMlockall option to jack_client_new) ?
>

Just run JACK with --no-mlock.

> As far as i can see even if the client does mlock() wrong
> and there's eventually a page fault inside it's process callback,
> in the worst case only that client will be kicked out,
> but jackd will continue to run.
>
> So why not allow those who are aware of the risks of
> no-mlockall() to do their stuff as they like?
>
> More precisely, my problem is the following: i use mmap() to
> simplify access to large wave file (exceeding phisycal memory).
> To have jack output in the same program, i have three options:
> - stop using mmap
> - fork all jack-related stuff to a separate process
> - require jackd with --no-mlock.
> Neither option seems attractive, but what else?
>

Why is --no-mlock a problem?

You could just call munlockall in your client.

Lee



_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

lars.luthman (Bugzilla)
On Mon, 2006-06-12 at 11:00 -0400, Lee Revell wrote:

> On Mon, 2006-06-12 at 13:55 +0200, Maxim Krikun wrote:
> > As far as i can see even if the client does mlock() wrong
> > and there's eventually a page fault inside it's process callback,
> > in the worst case only that client will be kicked out,
> > but jackd will continue to run.
> >
> > So why not allow those who are aware of the risks of
> > no-mlockall() to do their stuff as they like?
> >
> > More precisely, my problem is the following: i use mmap() to
> > simplify access to large wave file (exceeding phisycal memory).
> > To have jack output in the same program, i have three options:
> > - stop using mmap
> > - fork all jack-related stuff to a separate process
> > - require jackd with --no-mlock.
> > Neither option seems attractive, but what else?
> >
>
> Why is --no-mlock a problem?
>
> You could just call munlockall in your client.
Wouldn't this turn off locking in _all_ clients, including the ones that
don't want to handle memory locking themselves?

--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

lars.luthman (Bugzilla)
On Mon, 2006-06-12 at 17:08 +0200, Lars Luthman wrote:
> On Mon, 2006-06-12 at 11:00 -0400, Lee Revell wrote:
> >
> > Why is --no-mlock a problem?
> >
> > You could just call munlockall in your client.
>
> Wouldn't this turn off locking in _all_ clients, including the ones that
> don't want to handle memory locking themselves?

Uh, never mind. I misread that completely.

--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

Maxim Krikun
In reply to this post by Lee Revell
On 12/06/06, Lee Revell <[hidden email]> wrote:
> Just run JACK with --no-mlock.

you're right, that's a solution;

but if there was some way to avoid mlockall(), other
than asking the user to restart jack with specific options,
i would prefer that.  So my principal question was why
not skip mlockall() on client's demand.

>
> Why is --no-mlock a problem?

Because most users run jackd with memory locking on by default.
and if a program cannot run (or even hangs the whole systems)
with default jackd options, that's a bug.

And eventually there may exist some software (or some hardware
configuration) that requires memory locking to be on. Not good.

> You could just call munlockall in your client.

sure, but this can become quite tricky, and it makes re-activating
jackd near to impossible.


--Maxim


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

Lee Revell
On Mon, 2006-06-12 at 17:27 +0200, Maxim Krikun wrote:
> > You could just call munlockall in your client.
>
> sure, but this can become quite tricky, and it makes re-activating
> jackd near to impossible.

Why?  munlockall() does exactly what you want - it unlocks the memory in
only your client.

Lee



_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

Maxim Krikun
On 12/06/06, Lee Revell <[hidden email]> wrote:
>
> Why?  munlockall() does exactly what you want - it unlocks the memory in
> only your client.
>

i connect to jackd from python interpreter;
currently, if mlockall() is on, for some obscure reason
the systmen just hangs, so there's no chance to munlockall().
i agree, there must be a bug in my code, but still
if eventually jackd is restarted, it's not possible to
reconnect and munlockall() if there is some 1gb of
data mmaped to, say, 256mb RAM.

--Maxim


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

sbahling (Bugzilla)
On Wed, 2006-06-14 at 12:45 +0200, Maxim Krikun wrote:
> On 12/06/06, Lee Revell <[hidden email]> wrote:
> >
> > Why?  munlockall() does exactly what you want - it unlocks the memory in
> > only your client.
> >
>
> i connect to jackd from python interpreter;

[off topic] How are you accessing jackd from python? Custom modules? I
have seen PyJack but from what I remember is was broken or limited, and
development seemed to have stalled. I have been looking for a good way
to use audio from python, and jack would be optimal.

Thanks,

Scott


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

Dave Cunningham
>> i connect to jackd from python interpreter;
>
>[off topic] How are you accessing jackd from python? Custom modules? I
>have seen PyJack but from what I remember is was broken or limited, and
>development seemed to have stalled. I have been looking for a good way
>to use audio from python, and jack would be optimal.

i dont know much about python but i would have thought that
writing a realtime process() callback in python would be insane
when you dont know anything about dynamic memory allocation,
garbage collection, etc

maybe you want to write the process() callback in a lower
level langauge and use python for the gui stuff?


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

Maxim Krikun
On 17/06/06, Dave Cunningham <[hidden email]> wrote:
> >> i connect to jackd from python interpreter;
> >
> >[off topic] How are you accessing jackd from python? Custom modules? I
> >have seen PyJack but from what I remember is was broken or limited, and
> >development seemed to have stalled. I have been looking for a good way
> >to use audio from python, and jack would be optimal.
>
> i dont know much about python but i would have thought that
> writing a realtime process() callback in python would be insane

i didn't mean writing process() callback in python -- it's actually
done either in plain C, either in pyrex-translated-to-C.

the point is that at the moment i call jack_activate() there is
already lots of stuff loaded in process VM by the interpreter,
so i don't have complete control, and when everything hangs
on mlockall() i can't tell exactly why this happens.


--Maxim


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (again)

Jack O'Quin
On 6/17/06, Maxim Krikun <[hidden email]> wrote:

> the point is that at the moment i call jack_activate() there is
> already lots of stuff loaded in process VM by the interpreter,
> so i don't have complete control, and when everything hangs
> on mlockall() i can't tell exactly why this happens.

Maybe that address space is simply too big to be locked?
--
 joq


_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel