> I once attempted an approach involving an atomic counter of the number
> of "in flight" hugepages, only retrying when it's non zero. Working
> out a safe ordering for all the updates to get all the cases right
> made my brain melt though, and I never got it working.
I sent v2 few seconds
I once attempted an approach involving an atomic counter of the number
of in flight hugepages, only retrying when it's non zero. Working
out a safe ordering for all the updates to get all the cases right
made my brain melt though, and I never got it working.
I sent v2 few seconds before. My
On Wed, Aug 07, 2013 at 06:18:32PM +0900, Joonsoo Kim wrote:
> On Tue, Aug 06, 2013 at 06:38:49PM -0700, Davidlohr Bueso wrote:
> > On Wed, 2013-08-07 at 11:03 +1000, David Gibson wrote:
> > > On Tue, Aug 06, 2013 at 05:18:44PM -0700, Davidlohr Bueso wrote:
> > > > On Mon, 2013-08-05 at 16:36
On Wed, Aug 07, 2013 at 06:18:32PM +0900, Joonsoo Kim wrote:
On Tue, Aug 06, 2013 at 06:38:49PM -0700, Davidlohr Bueso wrote:
On Wed, 2013-08-07 at 11:03 +1000, David Gibson wrote:
On Tue, Aug 06, 2013 at 05:18:44PM -0700, Davidlohr Bueso wrote:
On Mon, 2013-08-05 at 16:36 +0900, Joonsoo
On Tue, Aug 06, 2013 at 06:38:49PM -0700, Davidlohr Bueso wrote:
> On Wed, 2013-08-07 at 11:03 +1000, David Gibson wrote:
> > On Tue, Aug 06, 2013 at 05:18:44PM -0700, Davidlohr Bueso wrote:
> > > On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
> > > > > Any mapping that doesn't use the
On Tue, Aug 06, 2013 at 06:38:49PM -0700, Davidlohr Bueso wrote:
On Wed, 2013-08-07 at 11:03 +1000, David Gibson wrote:
On Tue, Aug 06, 2013 at 05:18:44PM -0700, Davidlohr Bueso wrote:
On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
Any mapping that doesn't use the reserved pool,
On Wed, 2013-08-07 at 11:03 +1000, David Gibson wrote:
> On Tue, Aug 06, 2013 at 05:18:44PM -0700, Davidlohr Bueso wrote:
> > On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
> > > > Any mapping that doesn't use the reserved pool, not just
> > > > MAP_NORESERVE. For example, if a process
On Tue, Aug 06, 2013 at 05:18:44PM -0700, Davidlohr Bueso wrote:
> On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
> > > Any mapping that doesn't use the reserved pool, not just
> > > MAP_NORESERVE. For example, if a process makes a MAP_PRIVATE mapping,
> > > then fork()s then the mapping
On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
> > Any mapping that doesn't use the reserved pool, not just
> > MAP_NORESERVE. For example, if a process makes a MAP_PRIVATE mapping,
> > then fork()s then the mapping is instantiated in the child, that will
> > not draw from the reserved
On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
Any mapping that doesn't use the reserved pool, not just
MAP_NORESERVE. For example, if a process makes a MAP_PRIVATE mapping,
then fork()s then the mapping is instantiated in the child, that will
not draw from the reserved pool.
On Tue, Aug 06, 2013 at 05:18:44PM -0700, Davidlohr Bueso wrote:
On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
Any mapping that doesn't use the reserved pool, not just
MAP_NORESERVE. For example, if a process makes a MAP_PRIVATE mapping,
then fork()s then the mapping is
On Wed, 2013-08-07 at 11:03 +1000, David Gibson wrote:
On Tue, Aug 06, 2013 at 05:18:44PM -0700, Davidlohr Bueso wrote:
On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
Any mapping that doesn't use the reserved pool, not just
MAP_NORESERVE. For example, if a process makes a
> Any mapping that doesn't use the reserved pool, not just
> MAP_NORESERVE. For example, if a process makes a MAP_PRIVATE mapping,
> then fork()s then the mapping is instantiated in the child, that will
> not draw from the reserved pool.
>
> > Should we ensure them to allocate the last hugepage?
Any mapping that doesn't use the reserved pool, not just
MAP_NORESERVE. For example, if a process makes a MAP_PRIVATE mapping,
then fork()s then the mapping is instantiated in the child, that will
not draw from the reserved pool.
Should we ensure them to allocate the last hugepage?
They
On Wed, Jul 31, 2013 at 02:37:53PM +0900, Joonsoo Kim wrote:
> Hello, David.
>
> On Mon, Jul 29, 2013 at 05:28:23PM +1000, David Gibson wrote:
> > On Mon, Jul 29, 2013 at 02:32:08PM +0900, Joonsoo Kim wrote:
> > > If parallel fault occur, we can fail to allocate a hugepage,
> > > because many
On Wed, Jul 31, 2013 at 02:37:53PM +0900, Joonsoo Kim wrote:
Hello, David.
On Mon, Jul 29, 2013 at 05:28:23PM +1000, David Gibson wrote:
On Mon, Jul 29, 2013 at 02:32:08PM +0900, Joonsoo Kim wrote:
If parallel fault occur, we can fail to allocate a hugepage,
because many threads
Hello, David.
On Mon, Jul 29, 2013 at 05:28:23PM +1000, David Gibson wrote:
> On Mon, Jul 29, 2013 at 02:32:08PM +0900, Joonsoo Kim wrote:
> > If parallel fault occur, we can fail to allocate a hugepage,
> > because many threads dequeue a hugepage to handle a fault of same address.
> > This makes
Hello, David.
On Mon, Jul 29, 2013 at 05:28:23PM +1000, David Gibson wrote:
On Mon, Jul 29, 2013 at 02:32:08PM +0900, Joonsoo Kim wrote:
If parallel fault occur, we can fail to allocate a hugepage,
because many threads dequeue a hugepage to handle a fault of same address.
This makes
On Mon, Jul 29, 2013 at 02:32:08PM +0900, Joonsoo Kim wrote:
> If parallel fault occur, we can fail to allocate a hugepage,
> because many threads dequeue a hugepage to handle a fault of same address.
> This makes reserved pool shortage just for a little while and this cause
> faulting thread who
On Mon, Jul 29, 2013 at 02:32:08PM +0900, Joonsoo Kim wrote:
If parallel fault occur, we can fail to allocate a hugepage,
because many threads dequeue a hugepage to handle a fault of same address.
This makes reserved pool shortage just for a little while and this cause
faulting thread who is
If parallel fault occur, we can fail to allocate a hugepage,
because many threads dequeue a hugepage to handle a fault of same address.
This makes reserved pool shortage just for a little while and this cause
faulting thread who is ensured to have enough reserved hugepages
to get a SIGBUS signal.
If parallel fault occur, we can fail to allocate a hugepage,
because many threads dequeue a hugepage to handle a fault of same address.
This makes reserved pool shortage just for a little while and this cause
faulting thread who is ensured to have enough reserved hugepages
to get a SIGBUS signal.
22 matches
Mail list logo
