Re: [patch 0/7] cpuset writeback throttling

[Peter Zijlstra <peterz@infradead.org>]

On Tue, 2008-11-04 at 13:16 -0800, Andrew Morton wrote:
> On Tue, 04 Nov 2008 21:53:08 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Tue, 2008-11-04 at 12:47 -0800, Andrew Morton wrote:
> > > On Thu, 30 Oct 2008 12:23:10 -0700 (PDT)
> > > David Rientjes <rientjes@google.com> wrote:
> > > 
> > > > This is the revised cpuset writeback throttling patchset
> > > 
> > > I'm all confused about why this is a cpuset thing rather than a cgroups
> > > thing.  What are the relationships here?
> > > 
> > > I mean, writeback throttling _should_ operate upon a control group
> > > (more specifically: a memcg), yes?  I guess you're assuming a 1:1
> > > relationship here?
> > 
> > I think the main reason is that we have per-node vmstats so the cpuset
> > extention is relatively easy. Whereas we do not currently maintain
> > vmstats on a cgroup level - although I imagine that could be remedied.
> 
> It didn't look easy to me - it added a lot more code in places which are
> already wicked complex.
> 
> I'm trying to understand where this is all coming from and what fits
> into where.  Fiddling with a cpuset's mems_allowed for purposes of
> memory partitioning is all nasty 2007 technology, isn't it?  Does a raw
> cpuset-based control such as this have a future?

Yes, cpusets are making a come-back on the embedded multi-core Real-Time
side. Folks love to isolate stuff..

Not saying I really like it...

Also, there seems to be talk about node aware pdflush from the
filesystems folks, not sure we need cpusets for that, but this does seem
to add some node information into it.