linux-kernel - Re: [ckrm-tech] [RFC] Resource Management

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: <Pine.LNX.4.64N.0611021717570.12501@attu4.cs.washington.edu>
Date:	Thu, 2 Nov 2006 17:29:40 -0800 (PST)
From:	David Rientjes <rientjes@...washington.edu>
To:	Pavel Emelianov <xemul@...nvz.org>
cc:	Matt Helsley <matthltc@...ibm.com>, vatsa@...ibm.com,
	balbir@...ibm.com, Paul Menage <menage@...gle.com>, dev@...nvz.org,
	sekharan@...ibm.com, ckrm-tech@...ts.sourceforge.net,
	haveblue@...ibm.com, linux-kernel@...r.kernel.org, pj@....com,
	dipankar@...ibm.com, rohitseth@...gle.com
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

On Thu, 2 Nov 2006, Pavel Emelianov wrote:

> >> Beancounter may have more than 409 tasks, while configfs
> >> doesn't allow attributes to store more than PAGE_SIZE bytes
> >> on read. So how would you fill so many tasks in one page?
> > 
> > 	To be clear that's a limitation of configfs as an interface. In the
> > Resource Groups code, for example, there is no hard limitation on length
> > of the underlying list. This is why we're talking about a filesystem
> > interface and not necessarily a configfs interface.
> 
> David Rientjes persuaded me that writing our own file system is
> reimplementing the existing thing. If we've agreed with file system
> interface then configfs may be used. But the limitations I've
> pointed out must be discussed.
> 

What are we really discussing here?  The original issue that you raised 
with the infrastructure was an fs vs. syscall interface and I simply 
argued in favor of an fs-based approach because containers are inherently 
hierarchial.  As Paul Jackson mentioned, this is one of the advantages 
that cpusets has had since its inclusion in the kernel and the abstraction 
of cpusets from containers makes a convincing case for how beneficial it 
has been and will continue to be.

Regardless of whether configfs is specifically used for this particular 
purpose is irrelevant in deciding fs vs syscall.  Certainly it could be 
used for lightweight purposes but it by no means is the only possibility 
for containers.  I have observed no further advocation for a syscall 
interface; it seems like a no-brainer that if there are certain 
limitations on configfs that you have pointed out that would be 
disadvantageous to containers that another fs implementation would 
suffice.

> Let me remind:
> 1. limitation of size of data written out of configfs;
> 2. when configfs is a module user won't be able to
>    use beancounters.
> 
> and one new
> 3. now in beancounters we have /proc/user_beancounters
>    file that shows the complete statistics on BC. This
>    includes all then beancounters in the system with all
>    resources' held/maxheld/failcounters/etc. This is very
>    handy and "vividly": a simple 'cat' shows you all you
>    need. With configfs we lack this very handy feature.
> 

Ok, so each of these issues includes a specific criticism against configfs 
for containers.  So a different fs-based interface similiar to the cpuset 
abstraction from containers is certainly appropriate.

		David
-
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/