Li Zefan wrote:
>> Acked-by: Paul Menage <[EMAIL PROTECTED]>
>>
>> I might use the term "non-freezable" rather than "unfreezable".
>>
>
> My bad English :(
>
> patch updated. (some annoying leading tabs are also removed in the doc)
>
And I forgot to s/EIO/EINVAL in the document..
This patch sh
> Acked-by: Paul Menage <[EMAIL PROTECTED]>
>
> I might use the term "non-freezable" rather than "unfreezable".
>
My bad English :(
patch updated. (some annoying leading tabs are also removed in the doc)
From: Li Zefan <[EMAIL PROTECTED]>
Date: Tue, 4 Nov 2008 15:26:2
On Wed, 5 Nov 2008 14:04:42 -0800 (PST)
David Rientjes <[EMAIL PROTECTED]> wrote:
> > So the world wouldn't end if we just didn't merge it. Those users
> > stick with their workarounds and the kernel remains simpler and
> > smaller.
> >
>
> Agreed. This patchset is admittedly from a different
On Wed, Nov 5, 2008 at 5:18 PM, Li Zefan <[EMAIL PROTECTED]> wrote:
> With this change, control file 'freezer.state' doesn't exist in root
> cgroup, making root cgroup unfreezable.
>
> I think it's reasonable to disallow freeze tasks in the root cgroup.
> And then we can avoid fork overhead when fr
With this change, control file 'freezer.state' doesn't exist in root
cgroup, making root cgroup unfreezable.
I think it's reasonable to disallow freeze tasks in the root cgroup.
And then we can avoid fork overhead when freezer subsystem is
compiled but not used.
Also make writing invalid value to
On Tue, Nov 4, 2008 at 12:01 AM, Li Zefan <[EMAIL PROTECTED]> wrote:
> Paul Menage wrote:
>> On Mon, Nov 3, 2008 at 11:35 PM, Li Zefan <[EMAIL PROTECTED]> wrote:
>>> With this change, the root cgroup is unfreezable, and writing to
>>> its freezer.state returns -EIO.
>>
>> EINVAL might be more consi
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 05 Nov 2008 15:22:26 -0800
>
> When physical devices are inside of network namespace and that
> network namespace terminates we can not make them go away. We
> have to keep them and moving them to the initial network namespace
> is the best
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 05 Nov 2008 15:27:34 -0800
>
> I have been tracking for a while a case where when the
> network namespace exits the cleanup gets stck in an
> endless precessess of:
>
> unregister_netdevice: waiting for lo to become free. Usage count = 3
> u
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 05 Nov 2008 15:25:39 -0800
>
> I was recently hunting a bug that occurred in network namespace
> cleanup. In looking at the code it became apparrent that we have
> and will continue to have cases where if we have anything going
> on in a net
I was recently hunting a bug that occurred in network namespace
cleanup. In looking at the code it became apparrent that we have
and will continue to have cases where if we have anything going
on in a network namespace there will be assumptions that the
loopback device is present. Things like s
I have been tracking for a while a case where when the
network namespace exits the cleanup gets stck in an
endless precessess of:
unregister_netdevice: waiting for lo to become free. Usage count = 3
unregister_netdevice: waiting for lo to become free. Usage count = 3
unregister_netdevice: waiting
When physical devices are inside of network namespace and that
network namespace terminates we can not make them go away. We
have to keep them and moving them to the initial network namespace
is the best we can do.
For virtual devices left in a network namespace that is exiting
we have no need t
On Wed, 5 Nov 2008, Andrew Morton wrote:
> See, here's my problem: we have a pile of new code which fixes some
> problem. But the problem seems to be fairly small - it only affects a
> small number of sophisticated users and they already have workarounds
> in place.
>
The workarounds, while res
On Wed, Nov 5, 2008 at 12:56 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
>>
>> 1. Reduce the global dirty ratios so that the number of dirty pages in a
>> cpuset cannot become too high.
>
> That would be less than the smallest node's memory capacity, I guess.
Even that doesn't work - if there's a
On Wed, 5 Nov 2008 14:40:05 -0600 (CST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 5 Nov 2008, Andrew Morton wrote:
>
> > > That means running reclaim. But we are only interested in getting rid of
> > > dirty pages. Plus the filesystem guys have repeatedly pointed out that
> > > page
On Wed, 5 Nov 2008 14:21:47 -0600 (CST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 5 Nov 2008, Andrew Morton wrote:
>
> > > > Doable. lru->page->mapping->host is a good start.
> > >
> > > The block layer has a list of inodes that are dirty. From that we need to
> > > select ones that
Ian jonhson wrote:
> Thank Daniel, Serge, and all the friends in the maillist.
> Now, I have given a bird view about current status of container.
> The finial question is that how to do contribution:
> * what matters/fashion should I obey to develop codes?
> * how to upload my patch or my extension
Daniel Lezcano wrote:
> This patchset (not tested) shows how it is possible to create a socket
> specifying the network namespace destination. That should allow a single
> process to handle several network namespaces.
Vivien, Andreas,
does this patch fit your needs ? If so, I can ask for mainstre
On Wed, 5 Nov 2008 07:52:44 -0600 (CST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Nov 2008, Andrew Morton wrote:
>
> >> That is one aspect. When performing writeback then we need to figure out
> >> which inodes have dirty pages in the memcg and we need to start writeout
> >> on tho
Daniel Lezcano wrote:
> Ian jonhson wrote:
>> Dear all,
>>
>> I am now working in the development of user tool for container
>> (built by Daniel Lezcano) and interest in the accounting
>> of container. Now, I would like to know whether the patches stated
>> in:
>> http://lwn.net/Articles/229974/
>
Hello !
>> Or maybe just skip populating the file entirely for the root cgroup?
>> It's not useful if it can't be written and always returns the same
>> value.
>
> I thought about this. I'll see which way Matt and Cedric prefer.
I think that Paul's suggestion of disabling the root freezer makes
21 matches
Mail list logo
