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 function. Paul?
>
> The typical usage scenarios don't matter a lot: the examples I gave show
> that the core problem remains unsolved. People can still hit the bug.
I agree the overlap issue is a problem and I hope it can be addressed
somehow for the rare cases in which such nesting takes place.
One easy solution may be to check the dirty ratio before engaging in
reclaim. If the dirty ratio is sufficiently high then trigger writeout via
pdflush (we already wakeup pdflush while scanning and you already noted
that pdflush writeout is not occurring within the context of the current
cpuset) and pass over any dirty pages during LRU scans until some pages
have been cleaned up.
This means we allow allocation of additional kernel memory outside of the
cpuset while triggering writeout of inodes that have pages on the nodes
of the cpuset. The memory directly used by the application is still
limited. Just the temporary information needed for writeback is allocated
outside.
Well sounds somehow still like a hack. Any other ideas out there?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
