[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100118154149.38fa61d4@lxorguk.ukuu.org.uk>
Date: Mon, 18 Jan 2010 15:41:49 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Avi Kivity <avi@...hat.com>, Gleb Natapov <gleb@...hat.com>,
Pekka Enberg <penberg@...helsinki.fi>, linux-mm@...ck.org,
kosaki.motohiro@...fujitsu.com, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, akpm@...ux-foundation.org,
andrew.c.morrow@...il.com,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH v6] add MAP_UNLOCKED mmap flag
On Mon, 18 Jan 2010 16:24:07 +0100
Peter Zijlstra <peterz@...radead.org> wrote:
> On Mon, 2010-01-18 at 17:19 +0200, Avi Kivity wrote:
> > > I would not advice that, just mlock() the text and data you need for the
> > > real-time thread. mlockall() is a really blunt instrument.
> > >
> >
> > May not be feasible due to libraries.
>
> Esp for the real-time case I could advise not to use those libraries
> then, since they're clearly not designed for that use case.
In "hard" real time cases an awful lot of libraries have things like
memory allocations in them and don't care about stack growth which can
cause faults and sleeps. The memory allocator if you are running threaded
was not real time priority aware either last time I checked so the
standard libraries are not going to give the behaviour you want unless
you have a proper RT environment, and even then it may be a bit iffy here
and there.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists