linux-kernel - Re: [patch 0/7] cpuset writeback throttling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1225833710.7803.1993.camel@twins>
Date:	Tue, 04 Nov 2008 22:21:50 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	rientjes@...gle.com, cl@...ux-foundation.org, npiggin@...e.de,
	menage@...gle.com, dfults@....com, linux-kernel@...r.kernel.org
Subject: Re: [patch 0/7] cpuset writeback throttling

On Tue, 2008-11-04 at 13:16 -0800, Andrew Morton wrote:
> On Tue, 04 Nov 2008 21:53:08 +0100
> Peter Zijlstra <peterz@...radead.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@...gle.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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/