On Sat, 21 Apr 2007, Ethan Solomita wrote:
>Exactly -- your patch should be consistent and do it the same way as
> whatever your patch is built against. Your patch is built against a kernel
> that subtracts off highmem. "Do it..." are you handing off the patch and are
> done with it?
Yes as
Christoph Lameter wrote:
On Fri, 20 Apr 2007, Ethan Solomita wrote:
cpuset_write_dirty_map.htm
In __set_page_dirty_nobuffers() you always call cpuset_update_dirty_nodes()
but in __set_page_dirty_buffers() you call it only if page->mapping is still
set after locking. Is there a reason
Christoph Lameter wrote:
On Fri, 20 Apr 2007, Ethan Solomita wrote:
cpuset_write_dirty_map.htm
In __set_page_dirty_nobuffers() you always call cpuset_update_dirty_nodes()
but in __set_page_dirty_buffers() you call it only if page-mapping is still
set after locking. Is there a reason for
On Sat, 21 Apr 2007, Ethan Solomita wrote:
Exactly -- your patch should be consistent and do it the same way as
whatever your patch is built against. Your patch is built against a kernel
that subtracts off highmem. Do it... are you handing off the patch and are
done with it?
Yes as said
On Fri, 20 Apr 2007, Ethan Solomita wrote:
> cpuset_write_dirty_map.htm
>
>In __set_page_dirty_nobuffers() you always call cpuset_update_dirty_nodes()
> but in __set_page_dirty_buffers() you call it only if page->mapping is still
> set after locking. Is there a reason for the difference?
Christoph Lameter wrote:
H Sorry. I got distracted and I have sent them to Kame-san who was
interested in working on them.
I have placed the most recent version at
http://ftp.kernel.org/pub/linux/kernel/people/christoph/cpuset_dirty
Hi Christoph -- a few comments on the
Christoph Lameter wrote:
H Sorry. I got distracted and I have sent them to Kame-san who was
interested in working on them.
I have placed the most recent version at
http://ftp.kernel.org/pub/linux/kernel/people/christoph/cpuset_dirty
Hi Christoph -- a few comments on the
On Fri, 20 Apr 2007, Ethan Solomita wrote:
cpuset_write_dirty_map.htm
In __set_page_dirty_nobuffers() you always call cpuset_update_dirty_nodes()
but in __set_page_dirty_buffers() you call it only if page-mapping is still
set after locking. Is there a reason for the difference? Also a
On Thu, 19 Apr 2007, Ethan Solomita wrote:
> > H Sorry. I got distracted and I have sent them to Kame-san who was
> > interested in working on them.
> > I have placed the most recent version at
> > http://ftp.kernel.org/pub/linux/kernel/people/christoph/cpuset_dirty
> >
>
>Do you
Christoph Lameter wrote:
On Wed, 18 Apr 2007, Ethan Solomita wrote:
Any new ETA? I'm trying to decide whether to go back to your original
patches or wait for the new set. Adding new knobs isn't as important to me as
having something that fixes the core problem, so hopefully this isn't
Christoph Lameter wrote:
On Wed, 18 Apr 2007, Ethan Solomita wrote:
Any new ETA? I'm trying to decide whether to go back to your original
patches or wait for the new set. Adding new knobs isn't as important to me as
having something that fixes the core problem, so hopefully this isn't
On Thu, 19 Apr 2007, Ethan Solomita wrote:
H Sorry. I got distracted and I have sent them to Kame-san who was
interested in working on them.
I have placed the most recent version at
http://ftp.kernel.org/pub/linux/kernel/people/christoph/cpuset_dirty
Do you expect any
On Wed, 18 Apr 2007, Ethan Solomita wrote:
>Any new ETA? I'm trying to decide whether to go back to your original
> patches or wait for the new set. Adding new knobs isn't as important to me as
> having something that fixes the core problem, so hopefully this isn't waiting
> on them. They
Christoph Lameter wrote:
On Wed, 21 Mar 2007, Ethan Solomita wrote:
Christoph Lameter wrote:
On Thu, 1 Feb 2007, Ethan Solomita wrote:
Hi Christoph -- has anything come of resolving the NFS / OOM concerns
that
Andrew Morton expressed concerning the patch? I'd be happy to
Christoph Lameter wrote:
On Wed, 21 Mar 2007, Ethan Solomita wrote:
Christoph Lameter wrote:
On Thu, 1 Feb 2007, Ethan Solomita wrote:
Hi Christoph -- has anything come of resolving the NFS / OOM concerns
that
Andrew Morton expressed concerning the patch? I'd be happy to
On Wed, 18 Apr 2007, Ethan Solomita wrote:
Any new ETA? I'm trying to decide whether to go back to your original
patches or wait for the new set. Adding new knobs isn't as important to me as
having something that fixes the core problem, so hopefully this isn't waiting
on them. They could
On Wed, 21 Mar 2007, Andrew Morton wrote:
> > The NFS patch went into Linus tree a couple of days ago
>
> Did it fix the oom issues which you were observing?
Yes it reduced the dirty ratios to reasonable numbers in a simple copy
operation that created large amounts of dirty pages before. The
On Wed, 21 Mar 2007 14:29:42 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Mar 2007, Ethan Solomita wrote:
>
> > Christoph Lameter wrote:
> > > On Thu, 1 Feb 2007, Ethan Solomita wrote:
> > >
> > > >Hi Christoph -- has anything come of resolving the NFS / OOM
On Wed, 21 Mar 2007, Ethan Solomita wrote:
> Christoph Lameter wrote:
> > On Thu, 1 Feb 2007, Ethan Solomita wrote:
> >
> > >Hi Christoph -- has anything come of resolving the NFS / OOM concerns
> > > that
> > > Andrew Morton expressed concerning the patch? I'd be happy to see some
> > >
Christoph Lameter wrote:
On Thu, 1 Feb 2007, Ethan Solomita wrote:
Hi Christoph -- has anything come of resolving the NFS / OOM concerns that
Andrew Morton expressed concerning the patch? I'd be happy to see some
progress on getting this patch (i.e. the one you posted on 1/23) through.
On Wed, 21 Mar 2007, Ethan Solomita wrote:
Christoph Lameter wrote:
On Thu, 1 Feb 2007, Ethan Solomita wrote:
Hi Christoph -- has anything come of resolving the NFS / OOM concerns
that
Andrew Morton expressed concerning the patch? I'd be happy to see some
progress on getting
On Wed, 21 Mar 2007 14:29:42 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2007, Ethan Solomita wrote:
Christoph Lameter wrote:
On Thu, 1 Feb 2007, Ethan Solomita wrote:
Hi Christoph -- has anything come of resolving the NFS / OOM concerns
that
On Wed, 21 Mar 2007, Andrew Morton wrote:
The NFS patch went into Linus tree a couple of days ago
Did it fix the oom issues which you were observing?
Yes it reduced the dirty ratios to reasonable numbers in a simple copy
operation that created large amounts of dirty pages before. The
On Thu, 1 Feb 2007 21:29:06 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Thu, 1 Feb 2007, Andrew Morton wrote:
>
> > > Peter Zilkstra addressed the NFS issue.
> >
> > Did he? Are you yet in a position to confirm that?
>
> He provided a solution to fix the congestion issue in
On Thursday February 1, [EMAIL PROTECTED] wrote:
>
> > The network stack is of course a different (much harder) problem.
>
> An NFS solution is possible without solving the network stack issue?
NFS is currently able to make more than max_dirty_ratio of memory
Dirty/Writeback without being
On Fri, 2 Feb 2007, Neil Brown wrote:
> md/raid doesn't cause any problems here. It preallocates enough to be
> sure that it can always make forward progress. In general the entire
> block layer from generic_make_request down can always successfully
> write a block out in a reasonable amount of
On Thursday February 1, [EMAIL PROTECTED] wrote:
>The NFS problems also exist for non cpuset scenarios
> and we have by and large been able to live with it so I think they are
> lower priority. It seems that the basic problem is created by the dirty
> ratios in a cpuset.
On Thu, 1 Feb 2007, Andrew Morton wrote:
> > Peter Zilkstra addressed the NFS issue.
>
> Did he? Are you yet in a position to confirm that?
He provided a solution to fix the congestion issue in NFS. I thought
that is what you were looking for? That should make NFS behave more
like a block
On Thu, 1 Feb 2007 18:16:05 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Thu, 1 Feb 2007, Ethan Solomita wrote:
>
> >Hi Christoph -- has anything come of resolving the NFS / OOM concerns
> > that
> > Andrew Morton expressed concerning the patch? I'd be happy to see some
>
On Thu, 1 Feb 2007, Ethan Solomita wrote:
>Hi Christoph -- has anything come of resolving the NFS / OOM concerns that
> Andrew Morton expressed concerning the patch? I'd be happy to see some
> progress on getting this patch (i.e. the one you posted on 1/23) through.
Peter Zilkstra addressed
Hi Christoph -- has anything come of resolving the NFS / OOM
concerns that Andrew Morton expressed concerning the patch? I'd be happy
to see some progress on getting this patch (i.e. the one you posted on
1/23) through.
Thanks,
-- Ethan
-
To unsubscribe from this list: send the line
Hi Christoph -- has anything come of resolving the NFS / OOM
concerns that Andrew Morton expressed concerning the patch? I'd be happy
to see some progress on getting this patch (i.e. the one you posted on
1/23) through.
Thanks,
-- Ethan
-
To unsubscribe from this list: send the line
On Thu, 1 Feb 2007, Ethan Solomita wrote:
Hi Christoph -- has anything come of resolving the NFS / OOM concerns that
Andrew Morton expressed concerning the patch? I'd be happy to see some
progress on getting this patch (i.e. the one you posted on 1/23) through.
Peter Zilkstra addressed the
On Thu, 1 Feb 2007 18:16:05 -0800 (PST) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Thu, 1 Feb 2007, Ethan Solomita wrote:
Hi Christoph -- has anything come of resolving the NFS / OOM concerns
that
Andrew Morton expressed concerning the patch? I'd be happy to see some
progress
On Thu, 1 Feb 2007, Andrew Morton wrote:
Peter Zilkstra addressed the NFS issue.
Did he? Are you yet in a position to confirm that?
He provided a solution to fix the congestion issue in NFS. I thought
that is what you were looking for? That should make NFS behave more
like a block device
On Thursday February 1, [EMAIL PROTECTED] wrote:
The NFS problems also exist for non cpuset scenarios
and we have by and large been able to live with it so I think they are
lower priority. It seems that the basic problem is created by the dirty
ratios in a cpuset.
Some
On Fri, 2 Feb 2007, Neil Brown wrote:
md/raid doesn't cause any problems here. It preallocates enough to be
sure that it can always make forward progress. In general the entire
block layer from generic_make_request down can always successfully
write a block out in a reasonable amount of
On Thursday February 1, [EMAIL PROTECTED] wrote:
The network stack is of course a different (much harder) problem.
An NFS solution is possible without solving the network stack issue?
NFS is currently able to make more than max_dirty_ratio of memory
Dirty/Writeback without being
On Thu, 1 Feb 2007 21:29:06 -0800 (PST) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Thu, 1 Feb 2007, Andrew Morton wrote:
Peter Zilkstra addressed the NFS issue.
Did he? Are you yet in a position to confirm that?
He provided a solution to fix the congestion issue in NFS. I
On Wed, 17 Jan 2007, Andrew Morton wrote:
> > The problem there is that we do a GFP_ATOMIC allocation (no allocation
> > context) that may fail when the first page is dirtied. We must therefore
> > be able to subsequently allocate the nodemask_t in set_page_dirty().
> > Otherwise the first
> On Wed, 17 Jan 2007 17:10:25 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Wed, 17 Jan 2007, Andrew Morton wrote:
>
> > > The inode lock is not taken when the page is dirtied.
> >
> > The inode_lock is taken when the address_space's first page is dirtied. It
> > is
> >
On Wed, 17 Jan 2007, Andrew Morton wrote:
> > The inode lock is not taken when the page is dirtied.
>
> The inode_lock is taken when the address_space's first page is dirtied. It is
> also taken when the address_space's last dirty page is cleaned. So the place
> where the inode is added to and
> On Wed, 17 Jan 2007 11:43:42 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 16 Jan 2007, Andrew Morton wrote:
>
> > Do what blockdevs do: limit the number of in-flight requests (Peter's
> > recent patch seems to be doing that for us) (perhaps only when PF_MEMALLOC
> > is
On Tue, 16 Jan 2007, Andrew Morton wrote:
> Do what blockdevs do: limit the number of in-flight requests (Peter's
> recent patch seems to be doing that for us) (perhaps only when PF_MEMALLOC
> is in effect, to keep Trond happy) and implement a mempool for the NFS
> request critical store.
> On Wed, 17 Jan 2007 00:01:58 -0800 Paul Jackson <[EMAIL PROTECTED]> wrote:
> Andrew wrote:
> > - consider going off-cpuset for critical allocations.
>
> We do ... in mm/page_alloc.c:
>
> * This is the last chance, in general, before the goto nopage.
> * Ignore cpuset if
Andrew wrote:
> - consider going off-cpuset for critical allocations.
We do ... in mm/page_alloc.c:
* This is the last chance, in general, before the goto nopage.
* Ignore cpuset if GFP_ATOMIC (!wait) rather than fail alloc.
* See also cpuset_zone_allowed() comment in
Andrew wrote:
- consider going off-cpuset for critical allocations.
We do ... in mm/page_alloc.c:
* This is the last chance, in general, before the goto nopage.
* Ignore cpuset if GFP_ATOMIC (!wait) rather than fail alloc.
* See also cpuset_zone_allowed() comment in
On Wed, 17 Jan 2007 00:01:58 -0800 Paul Jackson [EMAIL PROTECTED] wrote:
Andrew wrote:
- consider going off-cpuset for critical allocations.
We do ... in mm/page_alloc.c:
* This is the last chance, in general, before the goto nopage.
* Ignore cpuset if GFP_ATOMIC
On Tue, 16 Jan 2007, Andrew Morton wrote:
Do what blockdevs do: limit the number of in-flight requests (Peter's
recent patch seems to be doing that for us) (perhaps only when PF_MEMALLOC
is in effect, to keep Trond happy) and implement a mempool for the NFS
request critical store.
On Wed, 17 Jan 2007 11:43:42 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Tue, 16 Jan 2007, Andrew Morton wrote:
Do what blockdevs do: limit the number of in-flight requests (Peter's
recent patch seems to be doing that for us) (perhaps only when PF_MEMALLOC
is in effect,
On Wed, 17 Jan 2007, Andrew Morton wrote:
The inode lock is not taken when the page is dirtied.
The inode_lock is taken when the address_space's first page is dirtied. It is
also taken when the address_space's last dirty page is cleaned. So the place
where the inode is added to and
On Wed, 17 Jan 2007 17:10:25 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Wed, 17 Jan 2007, Andrew Morton wrote:
The inode lock is not taken when the page is dirtied.
The inode_lock is taken when the address_space's first page is dirtied. It
is
also taken when the
On Wed, 17 Jan 2007, Andrew Morton wrote:
The problem there is that we do a GFP_ATOMIC allocation (no allocation
context) that may fail when the first page is dirtied. We must therefore
be able to subsequently allocate the nodemask_t in set_page_dirty().
Otherwise the first failure
> On Tue, 16 Jan 2007 22:27:36 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 16 Jan 2007, Andrew Morton wrote:
>
> > > Yes this is the result of the hierachical nature of cpusets which already
> > > causes issues with the scheduler. It is rather typical that cpusets are
On Tue, 16 Jan 2007, Andrew Morton wrote:
> > Yes this is the result of the hierachical nature of cpusets which already
> > causes issues with the scheduler. It is rather typical that cpusets are
> > used to partition the memory and cpus. Overlappig cpusets seem to have
> > mainly an
> On Tue, 16 Jan 2007 19:40:17 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 16 Jan 2007, Andrew Morton wrote:
>
> > Consider: non-exclusive cpuset A consists of mems 0-15, non-exclusive
> > cpuset B consists of mems 0-3. A task running in cpuset A can freely dirty
> >
> Yes this is the result of the hierachical nature of cpusets which already
> causes issues with the scheduler. It is rather typical that cpusets are
> used to partition the memory and cpus. Overlappig cpusets seem to have
> mainly an administrative function. Paul?
The heavy weight tasks,
On Tue, 16 Jan 2007, Andrew Morton wrote:
> Consider: non-exclusive cpuset A consists of mems 0-15, non-exclusive
> cpuset B consists of mems 0-3. A task running in cpuset A can freely dirty
> all of cpuset B's memory. A task running in cpuset B gets oomkilled.
>
> Consider: a 32-node machine
> On Tue, 16 Jan 2007 17:30:26 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> > Nope. You've completely omitted the little fact that we'll do writeback in
> > the offending zone off the LRU. Slower, maybe. But it should work and the
> > system should recover. If it's not doing
On Tue, 16 Jan 2007, Andrew Morton wrote:
> Nope. You've completely omitted the little fact that we'll do writeback in
> the offending zone off the LRU. Slower, maybe. But it should work and the
> system should recover. If it's not doing that (it isn't) then we should
> fix it rather than
> On Tue, 16 Jan 2007 16:16:30 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 16 Jan 2007, Andrew Morton wrote:
>
> > It's a workaround for a still-unfixed NFS problem.
>
> No its doing proper throttling. Without this patchset there will *no*
> writeback and throttling at
On Tue, 16 Jan 2007, Andrew Morton wrote:
> It's a workaround for a still-unfixed NFS problem.
No its doing proper throttling. Without this patchset there will *no*
writeback and throttling at all. F.e. lets say we have 20 nodes of 1G each
and a cpuset that only spans one node.
Then a process
On Tue, Jan 16, 2007 at 01:53:25PM -0800, Andrew Morton wrote:
> > On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter
> > <[EMAIL PROTECTED]> wrote:
> >
> > Currently cpusets are not able to do proper writeback since dirty ratio
> > calculations and writeback are all done for the system as
> On Tue, 16 Jan 2007 14:15:56 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
>
> ...
>
> > > This may result in a large percentage of a cpuset
> > > to become dirty without writeout being triggered. Under NFS
> > > this can lead to OOM conditions.
> >
> > OK, a big question: is this
On Wed, 17 Jan 2007, Andi Kleen wrote:
> > Secondly we modify the dirty limit calculation to be based
> > on the acctive cpuset.
>
> The global dirty limit definitely seems to be a problem
> in several cases, but my feeling is that the cpuset is the wrong unit
> to keep track of it. Most likely
On Tue, 16 Jan 2007, Andrew Morton wrote:
> > On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter <[EMAIL
> > PROTECTED]> wrote:
> >
> > Currently cpusets are not able to do proper writeback since
> > dirty ratio calculations and writeback are all done for the system
> > as a whole.
>
>
> Secondly we modify the dirty limit calculation to be based
> on the acctive cpuset.
The global dirty limit definitely seems to be a problem
in several cases, but my feeling is that the cpuset is the wrong unit
to keep track of it. Most likely it should be more fine grained.
> If we are in a
> On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
>
> Currently cpusets are not able to do proper writeback since
> dirty ratio calculations and writeback are all done for the system
> as a whole.
We _do_ do proper writeback. But it's less efficient than
On Tue, 16 Jan 2007, Peter Zijlstra wrote:
> > B. We add a new counter NR_UNRECLAIMABLE that is subtracted
> >from the available pages in a node. This allows us to
> >accurately calculate the dirty ratio even if large portions
> >of the node have been allocated for huge pages or for
>
On Tue, 16 Jan 2007, Paul Jackson wrote:
> > 1. The nodemask expands the inode structure significantly if the
> > architecture allows a high number of nodes. This is only an issue
> > for IA64.
>
> Should that logic be disabled if HOTPLUG is configured on? Or is
> nr_node_ids a valid upper
Christoph wrote:
> Currently cpusets are not able to do proper writeback since
> dirty ratio calculations and writeback are all done for the system
> as a whole.
Thanks for tackling this - it is sorely needed.
I'm afraid my review will be mostly cosmetic; I'm not competent
to comment on the
Christoph wrote:
Currently cpusets are not able to do proper writeback since
dirty ratio calculations and writeback are all done for the system
as a whole.
Thanks for tackling this - it is sorely needed.
I'm afraid my review will be mostly cosmetic; I'm not competent
to comment on the really
On Tue, 16 Jan 2007, Paul Jackson wrote:
1. The nodemask expands the inode structure significantly if the
architecture allows a high number of nodes. This is only an issue
for IA64.
Should that logic be disabled if HOTPLUG is configured on? Or is
nr_node_ids a valid upper limit on
On Tue, 16 Jan 2007, Peter Zijlstra wrote:
B. We add a new counter NR_UNRECLAIMABLE that is subtracted
from the available pages in a node. This allows us to
accurately calculate the dirty ratio even if large portions
of the node have been allocated for huge pages or for
slab
On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
Currently cpusets are not able to do proper writeback since
dirty ratio calculations and writeback are all done for the system
as a whole.
We _do_ do proper writeback. But it's less efficient than it might
Secondly we modify the dirty limit calculation to be based
on the acctive cpuset.
The global dirty limit definitely seems to be a problem
in several cases, but my feeling is that the cpuset is the wrong unit
to keep track of it. Most likely it should be more fine grained.
If we are in a
On Tue, 16 Jan 2007, Andrew Morton wrote:
On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
Currently cpusets are not able to do proper writeback since
dirty ratio calculations and writeback are all done for the system
as a whole.
We _do_ do
On Wed, 17 Jan 2007, Andi Kleen wrote:
Secondly we modify the dirty limit calculation to be based
on the acctive cpuset.
The global dirty limit definitely seems to be a problem
in several cases, but my feeling is that the cpuset is the wrong unit
to keep track of it. Most likely it
On Tue, 16 Jan 2007 14:15:56 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
...
This may result in a large percentage of a cpuset
to become dirty without writeout being triggered. Under NFS
this can lead to OOM conditions.
OK, a big question: is this patchset a
On Tue, Jan 16, 2007 at 01:53:25PM -0800, Andrew Morton wrote:
On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter
[EMAIL PROTECTED] wrote:
Currently cpusets are not able to do proper writeback since dirty ratio
calculations and writeback are all done for the system as a whole.
On Tue, 16 Jan 2007, Andrew Morton wrote:
It's a workaround for a still-unfixed NFS problem.
No its doing proper throttling. Without this patchset there will *no*
writeback and throttling at all. F.e. lets say we have 20 nodes of 1G each
and a cpuset that only spans one node.
Then a process
On Tue, 16 Jan 2007 16:16:30 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Tue, 16 Jan 2007, Andrew Morton wrote:
It's a workaround for a still-unfixed NFS problem.
No its doing proper throttling. Without this patchset there will *no*
writeback and throttling at all. F.e.
On Tue, 16 Jan 2007, Andrew Morton wrote:
Nope. You've completely omitted the little fact that we'll do writeback in
the offending zone off the LRU. Slower, maybe. But it should work and the
system should recover. If it's not doing that (it isn't) then we should
fix it rather than
On Tue, 16 Jan 2007 17:30:26 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
Nope. You've completely omitted the little fact that we'll do writeback in
the offending zone off the LRU. Slower, maybe. But it should work and the
system should recover. If it's not doing that (it
On Tue, 16 Jan 2007, Andrew Morton wrote:
Consider: non-exclusive cpuset A consists of mems 0-15, non-exclusive
cpuset B consists of mems 0-3. A task running in cpuset A can freely dirty
all of cpuset B's memory. A task running in cpuset B gets oomkilled.
Consider: a 32-node machine has
Yes this is the result of the hierachical nature of cpusets which already
causes issues with the scheduler. It is rather typical that cpusets are
used to partition the memory and cpus. Overlappig cpusets seem to have
mainly an administrative function. Paul?
The heavy weight tasks, which
On Tue, 16 Jan 2007 19:40:17 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Tue, 16 Jan 2007, Andrew Morton wrote:
Consider: non-exclusive cpuset A consists of mems 0-15, non-exclusive
cpuset B consists of mems 0-3. A task running in cpuset A can freely dirty
all of cpuset
On Tue, 16 Jan 2007, Andrew Morton wrote:
Yes this is the result of the hierachical nature of cpusets which already
causes issues with the scheduler. It is rather typical that cpusets are
used to partition the memory and cpus. Overlappig cpusets seem to have
mainly an administrative
On Tue, 16 Jan 2007 22:27:36 -0800 (PST) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Tue, 16 Jan 2007, Andrew Morton wrote:
Yes this is the result of the hierachical nature of cpusets which already
causes issues with the scheduler. It is rather typical that cpusets are
used to
On Mon, 2007-01-15 at 21:47 -0800, Christoph Lameter wrote:
> Currently cpusets are not able to do proper writeback since
> dirty ratio calculations and writeback are all done for the system
> as a whole. This may result in a large percentage of a cpuset
> to become dirty without writeout being
Currently cpusets are not able to do proper writeback since
dirty ratio calculations and writeback are all done for the system
as a whole. This may result in a large percentage of a cpuset
to become dirty without writeout being triggered. Under NFS
this can lead to OOM conditions.
Writeback will
Currently cpusets are not able to do proper writeback since
dirty ratio calculations and writeback are all done for the system
as a whole. This may result in a large percentage of a cpuset
to become dirty without writeout being triggered. Under NFS
this can lead to OOM conditions.
Writeback will
On Mon, 2007-01-15 at 21:47 -0800, Christoph Lameter wrote:
Currently cpusets are not able to do proper writeback since
dirty ratio calculations and writeback are all done for the system
as a whole. This may result in a large percentage of a cpuset
to become dirty without writeout being
93 matches
Mail list logo
