On Thu, Aug 23, 2007 at 11:26:48AM +0200, Peter Zijlstra wrote:
> On Thu, 2007-08-23 at 05:38 +0200, Nick Piggin wrote:
> > On Tue, Aug 21, 2007 at 04:07:15PM +0200, Peter Zijlstra wrote:
> > > On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote:
> > > >
> > > > Although interestingly, we are
On Thu, 2007-08-23 at 14:11 +0400, Nikita Danilov wrote:
> Peter Zijlstra writes:
>
> [...]
>
> > My idea is to extend kswapd, run cpus_per_node instances of kswapd per
> > node for each of GFP_KERNEL, GFP_NOFS, GFP_NOIO. (basically 3 kswapds
> > per cpu)
> >
> > whenever we would hit
Peter Zijlstra writes:
[...]
> My idea is to extend kswapd, run cpus_per_node instances of kswapd per
> node for each of GFP_KERNEL, GFP_NOFS, GFP_NOIO. (basically 3 kswapds
> per cpu)
>
> whenever we would hit direct reclaim, add ourselves to a special
> waitqueue corresponding to the
On Thu, 2007-08-23 at 05:38 +0200, Nick Piggin wrote:
> On Tue, Aug 21, 2007 at 04:07:15PM +0200, Peter Zijlstra wrote:
> > On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote:
> > >
> > > Although interestingly, we are not guaranteed to have enough memory to
> > > completely initialise writeout
On Thu, 2007-08-23 at 05:38 +0200, Nick Piggin wrote:
On Tue, Aug 21, 2007 at 04:07:15PM +0200, Peter Zijlstra wrote:
On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote:
Although interestingly, we are not guaranteed to have enough memory to
completely initialise writeout of a single
Peter Zijlstra writes:
[...]
My idea is to extend kswapd, run cpus_per_node instances of kswapd per
node for each of GFP_KERNEL, GFP_NOFS, GFP_NOIO. (basically 3 kswapds
per cpu)
whenever we would hit direct reclaim, add ourselves to a special
waitqueue corresponding to the type of
On Thu, 2007-08-23 at 14:11 +0400, Nikita Danilov wrote:
Peter Zijlstra writes:
[...]
My idea is to extend kswapd, run cpus_per_node instances of kswapd per
node for each of GFP_KERNEL, GFP_NOFS, GFP_NOIO. (basically 3 kswapds
per cpu)
whenever we would hit direct reclaim,
On Thu, Aug 23, 2007 at 11:26:48AM +0200, Peter Zijlstra wrote:
On Thu, 2007-08-23 at 05:38 +0200, Nick Piggin wrote:
On Tue, Aug 21, 2007 at 04:07:15PM +0200, Peter Zijlstra wrote:
On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote:
Although interestingly, we are not guaranteed
On Tue, Aug 21, 2007 at 04:07:15PM +0200, Peter Zijlstra wrote:
> On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote:
> >
> > Although interestingly, we are not guaranteed to have enough memory to
> > completely initialise writeout of a single page.
>
> Yes, that is due to the unbounded nature
On Tue, Aug 21, 2007 at 04:07:15PM +0200, Peter Zijlstra wrote:
On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote:
Although interestingly, we are not guaranteed to have enough memory to
completely initialise writeout of a single page.
Yes, that is due to the unbounded nature of
On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote:
> On Mon, Aug 20, 2007 at 11:14:08PM +0200, Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 13:27 -0700, Christoph Lameter wrote:
> > > On Mon, 20 Aug 2007, Peter Zijlstra wrote:
> > >
> > > > > Plus the same issue can happen today. Writes are
On Mon, 2007-08-20 at 14:17 -0700, Christoph Lameter wrote:
> On Mon, 20 Aug 2007, Peter Zijlstra wrote:
>
> > > Its not that different.
> >
> > Yes it is, disk based completion does not require memory, network based
> > completion requires unbounded memory.
>
> Disk based completion only
On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote:
On Mon, Aug 20, 2007 at 11:14:08PM +0200, Peter Zijlstra wrote:
On Mon, 2007-08-20 at 13:27 -0700, Christoph Lameter wrote:
On Mon, 20 Aug 2007, Peter Zijlstra wrote:
Plus the same issue can happen today. Writes are usually not
On Mon, 2007-08-20 at 14:17 -0700, Christoph Lameter wrote:
On Mon, 20 Aug 2007, Peter Zijlstra wrote:
Its not that different.
Yes it is, disk based completion does not require memory, network based
completion requires unbounded memory.
Disk based completion only require no memory
On Mon, Aug 20, 2007 at 11:14:08PM +0200, Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 13:27 -0700, Christoph Lameter wrote:
> > On Mon, 20 Aug 2007, Peter Zijlstra wrote:
> >
> > > > Plus the same issue can happen today. Writes are usually not completed
> > > > during reclaim. If the writes
On Mon, 20 Aug 2007, Peter Zijlstra wrote:
> > Its not that different.
>
> Yes it is, disk based completion does not require memory, network based
> completion requires unbounded memory.
Disk based completion only require no memory if its not on a stack of
other devices and if the interrupt
On Mon, 2007-08-20 at 13:27 -0700, Christoph Lameter wrote:
> On Mon, 20 Aug 2007, Peter Zijlstra wrote:
>
> > > Plus the same issue can happen today. Writes are usually not completed
> > > during reclaim. If the writes are sufficiently deferred then you have the
> > > same issue now.
> >
> >
On Mon, 20 Aug 2007, Peter Zijlstra wrote:
> > Plus the same issue can happen today. Writes are usually not completed
> > during reclaim. If the writes are sufficiently deferred then you have the
> > same issue now.
>
> Once we have initiated (disk) writeout we do not need more memory to
>
On Mon, 2007-08-20 at 12:00 -0700, Christoph Lameter wrote:
> On Sat, 18 Aug 2007, Pavel Machek wrote:
>
> > > The reclaim is of particular important to stacked filesystems that may
> > > do a lot of allocations in the write path. Reclaim will be working
> > > as long as there are clean file
On Sat, 18 Aug 2007, Pavel Machek wrote:
> > The reclaim is of particular important to stacked filesystems that may
> > do a lot of allocations in the write path. Reclaim will be working
> > as long as there are clean file backed pages to reclaim.
>
> I don't get it. Lets say that we have
On Sat, 18 Aug 2007, Pavel Machek wrote:
The reclaim is of particular important to stacked filesystems that may
do a lot of allocations in the write path. Reclaim will be working
as long as there are clean file backed pages to reclaim.
I don't get it. Lets say that we have stacked
On Mon, 2007-08-20 at 12:00 -0700, Christoph Lameter wrote:
On Sat, 18 Aug 2007, Pavel Machek wrote:
The reclaim is of particular important to stacked filesystems that may
do a lot of allocations in the write path. Reclaim will be working
as long as there are clean file backed pages to
On Mon, 20 Aug 2007, Peter Zijlstra wrote:
Plus the same issue can happen today. Writes are usually not completed
during reclaim. If the writes are sufficiently deferred then you have the
same issue now.
Once we have initiated (disk) writeout we do not need more memory to
complete it,
On Mon, 2007-08-20 at 13:27 -0700, Christoph Lameter wrote:
On Mon, 20 Aug 2007, Peter Zijlstra wrote:
Plus the same issue can happen today. Writes are usually not completed
during reclaim. If the writes are sufficiently deferred then you have the
same issue now.
Once we have
On Mon, 20 Aug 2007, Peter Zijlstra wrote:
Its not that different.
Yes it is, disk based completion does not require memory, network based
completion requires unbounded memory.
Disk based completion only require no memory if its not on a stack of
other devices and if the interrupt handles
On Mon, Aug 20, 2007 at 11:14:08PM +0200, Peter Zijlstra wrote:
On Mon, 2007-08-20 at 13:27 -0700, Christoph Lameter wrote:
On Mon, 20 Aug 2007, Peter Zijlstra wrote:
Plus the same issue can happen today. Writes are usually not completed
during reclaim. If the writes are
Hi!
> If we exhaust the reserves in the page allocator when PF_MEMALLOC is set
> then no longer give up but call into reclaim with PF_MEMALLOC set.
>
> This is in essence a recursive call back into page reclaim with another
> page flag (__GFP_NOMEMALLOC) set. The recursion is bounded since
Hi!
If we exhaust the reserves in the page allocator when PF_MEMALLOC is set
then no longer give up but call into reclaim with PF_MEMALLOC set.
This is in essence a recursive call back into page reclaim with another
page flag (__GFP_NOMEMALLOC) set. The recursion is bounded since potential
If we exhaust the reserves in the page allocator when PF_MEMALLOC is set
then no longer give up but call into reclaim with PF_MEMALLOC set.
This is in essence a recursive call back into page reclaim with another
page flag (__GFP_NOMEMALLOC) set. The recursion is bounded since potential
If we exhaust the reserves in the page allocator when PF_MEMALLOC is set
then no longer give up but call into reclaim with PF_MEMALLOC set.
This is in essence a recursive call back into page reclaim with another
page flag (__GFP_NOMEMALLOC) set. The recursion is bounded since potential
30 matches
Mail list logo
