[Devel] Re: [PATCH 6/7] Containers (V8): BeanCounters over generic process containers

2007-04-09 Thread Pavel Emelianov
[EMAIL PROTECTED] wrote: This patch implements the BeanCounter resource control abstraction over generic process containers. It contains the beancounter core code, plus the numfiles resource counter. It doesn't currently contain any of the memory tracking code or the code for switching

[Devel] /proc/*/pagemap BUG: sleeping function called from invalid context

2007-04-09 Thread Alexey Dobriyan
After cat /proc/self/pagemap BUG: sleeping function called from invalid context at include/asm/uaccess.h:453 in_atomic():1, irqs_disabled():0 1 lock held by cat/14183: #0: (mm-mmap_sem){}, at: [c017d17b] pagemap_read+0x11f/0x21b [c01b7bc7] copy_to_user+0x37/0x4c [c017cf92]

[Devel] [PATCH 0/8] RSS controller based on process containers (v2)

2007-04-09 Thread Pavel Emelianov
Adds RSS accounting and control within a container. Major change: current scanner code reuse. Tasks and files accounting is not included as these containers are simple enough to be implemented later. Based on top of Paul Menage's container subsystem v8. Note, that only first three patches from

[Devel] [PATCH 1/8] Resource counters

2007-04-09 Thread Pavel Emelianov
Introduce generic structures and routines for resource accounting. Each resource accounting container is supposed to aggregate it, container_subsystem_state and its resource-specific members within. diff -upr linux-2.6.20.orig/include/linux/res_counter.h

[Devel] [PATCH 3/8] Add container pointer on mm_struct

2007-04-09 Thread Pavel Emelianov
Naturally mm_struct determines the resource consumer in memory accounting. So each mm_struct should have a pointer on container it belongs to. When a new task is created its mm_struct is assigned to the container this task belongs to. diff -upr linux-2.6.20.orig/include/linux/sched.h

[Devel] [PATCH 7/8] Page scanner changes needed to implement per-container scanner

2007-04-09 Thread Pavel Emelianov
Struct scan_control now carries: * the RSS container to free pages in; * pointer to an isolate_pages() function to isolate pages needed for the reclamation. diff -upr linux-2.6.20.orig/mm/vmscan.c linux-2.6.20-2/mm/vmscan.c --- linux-2.6.20.orig/mm/vmscan.c 2007-03-06 19:09:50.0

[Devel] [PATCH 8/8] Per-container pages reclamation

2007-04-09 Thread Pavel Emelianov
Implement try_to_free_pages_in_container() to free the pages in container that has run out of memory. The scan_control-isolate_pages() function isolates the container pages only. diff -upr linux-2.6.20.orig/include/linux/swap.h linux-2.6.20-2/include/linux/swap.h ---

[Devel] Re: [patch 0/8] unprivileged mount syscall

2007-04-09 Thread Serge E. Hallyn
Quoting Miklos Szeredi ([EMAIL PROTECTED]): This patchset adds support for keeping mount ownership information in the kernel, and allow unprivileged mount(2) and umount(2) in certain cases. No replies, huh? All we need is a comment from Andrew, and the replies come flooding in ;)

[Devel] Re: [PATCH 0/8] RSS controller based on process containers (v2)

2007-04-09 Thread Peter Zijlstra
*ugh* /me no like. The basic premises seems to be that we can track page owners perfectly (although this patch set does not yet do so), through get/release operations (on _mapcount). This is simply not true for unmapped pagecache pages. Those receive no 'release' event; (the usage by

[Devel] Re: [patch 0/8] unprivileged mount syscall

2007-04-09 Thread Serge E. Hallyn
Quoting Miklos Szeredi ([EMAIL PROTECTED]): One thing that is missing from this series is the ability to restrict user mounts to private namespaces. The reason is that private namespaces have still not gained the momentum and support needed for painless user experience. So

[Devel] Re: [PATCH 6/7] Containers (V8): BeanCounters over generic process containers

2007-04-09 Thread William Lee Irwin III
On Fri, Apr 06, 2007 at 04:32:27PM -0700, [EMAIL PROTECTED] wrote: This patch implements the BeanCounter resource control abstraction over generic process containers. It contains the beancounter core code, plus the numfiles resource counter. It doesn't currently contain any of the memory

[Devel] Re: [PATCH] net: Add etun driver

2007-04-09 Thread Ben Greear
Patrick McHardy wrote: It would be nice if someone would finally come up with a generic interface based on netlink (RTM_NEWLINK) instead of adding yet another couple of homegrown interfaces. My preference is for ioctls, procfs, or similar that does not require extra libraries. Ethtool is an

[Devel] Re: [patch 0/8] unprivileged mount syscall

2007-04-09 Thread H. Peter Anvin
Ram Pai wrote: It is in FC6. I dont know the status off upstream util-linux. I did submit the patch many times to Adrian Bunk (the then util-linux maintainer) and got no response. I have not pushed the patches to the new maintainer(Karel Zak?) though. Well, do that, then :) Seriously.

[Devel] Re: [PATCH] net: Add etun driver

2007-04-09 Thread David Miller
From: Ben Greear [EMAIL PROTECTED] Date: Mon, 09 Apr 2007 11:14:52 -0700 Patrick McHardy wrote: It would be nice if someone would finally come up with a generic interface based on netlink (RTM_NEWLINK) instead of adding yet another couple of homegrown interfaces. My preference is for

[Devel] Re: [PATCH] net: Add etun driver

2007-04-09 Thread David Miller
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 09 Apr 2007 18:58:13 +0200 It would be nice if someone would finally come up with a generic interface based on netlink (RTM_NEWLINK) instead of adding yet another couple of homegrown interfaces. I absolutely agree, using these ioctls and

[Devel] Re: [PATCH] net: Add etun driver

2007-04-09 Thread Jeff Garzik
Eric W. Biederman wrote: Nor have I seen a rigorous adherence to all new network configuration using netlink. The wireless code doesn't even seem to really try. Not true: commit 711e2c33ac9221a419a9e28d05dd78a6a9c5fd4d Author: Jean Tourrilhes [EMAIL PROTECTED] Date: Wed Feb 22 15:10:56

[Devel] Re: [PATCH] net: Add etun driver

2007-04-09 Thread Patrick McHardy
Johannes Berg wrote: On Mon, 2007-04-09 at 22:11 +0200, Patrick McHardy wrote: Thats why I suggested that we should create one, ideally before adding more sysfs/proc/ioctl/... based interfaces, which we'll have a hard time getting rid of again. But then how would we configure initial