I just got an idea -- what about organizing a one-day "containers
mini-summit" just before the Kernel Summit? We can all meet face to
face, discuss all the issues and come out with a good plan for KS talk.
That does not mean we shouldn't discuss it here, of course -- it's just
to make it "polis
Pavel Emelianov [EMAIL PROTECTED] wrote:
| Add kmem_cache to pid_namespace to allocate pids from.
|
| Since booth implementations expand the struct pid to carry
| more numerical values each namespace should have separate
| cache to store pids of different sizes.
|
| Each kmem cache is names "pid_
On Wed 11-07-07 13:55:30, Chuck Ebbert wrote:
> On 07/09/2007 02:14 PM, Jan Kara wrote:
> > Hi Andrew,
> >
> > it seems we've accidentally lost one JBD fix (probably it was my mistake
> > when rediffing some checkpointing changes) as Kirill has noted. A
> > transaction
> > can currently be re
Pavel Emelianov [EMAIL PROTECTED] wrote:
| Serge E. Hallyn wrote:
| > Quoting Pavel Emelianov ([EMAIL PROTECTED]):
| >> [EMAIL PROTECTED] wrote:
| >>> Pavel Emelianov [EMAIL PROTECTED] wrote:
| >>> | [EMAIL PROTECTED] wrote:
| >>> | > Subject: [PATCH 2/6] Rename pid_nr function
| >>> | >
| >>> |
Serge E. Hallyn wrote:
> Quoting Pavel Emelianov ([EMAIL PROTECTED]):
>> [EMAIL PROTECTED] wrote:
>>> Pavel Emelianov [EMAIL PROTECTED] wrote:
>>> | [EMAIL PROTECTED] wrote:
>>> | > Subject: [PATCH 2/6] Rename pid_nr function
>>> | >
>>> | > From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
>>> | >
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> [EMAIL PROTECTED] wrote:
> > Pavel Emelianov [EMAIL PROTECTED] wrote:
> > | [EMAIL PROTECTED] wrote:
> > | > Subject: [PATCH 2/6] Rename pid_nr function
> > | >
> > | > From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
> > | >
> > | > Rename pid_nr() fu
On 07/09/2007 02:14 PM, Jan Kara wrote:
> Hi Andrew,
>
> it seems we've accidentally lost one JBD fix (probably it was my mistake
> when rediffing some checkpointing changes) as Kirill has noted. A transaction
> can currently be released when there are still some buffers on one of its
> checkp
Am Mittwoch, 11. Juli 2007 schrieb Pavel Emelianov:
> drivers/net/veth.c | 452
> include/net/veth.h | 14 +
I know, I am late in the game, but wont the name collide somewhat with
drivers/net/ibmveth.h, drivers/net/iseries_veth.c, and drivers/net/ibmveth.c?
Christian
___
> On 7/10/07, YAMAMOTO Takashi <[EMAIL PROTECTED]> wrote:
> > hi,
> >
> > > diff -puN mm/memory.c~mem-control-accounting mm/memory.c
> > > --- linux-2.6.22-rc6/mm/memory.c~mem-control-accounting 2007-07-05
> > > 13:45:18.0 -0700
> > > +++ linux-2.6.22-rc6-balbir/mm/memory.c 200
> Add the meta_page to the per container LRU. The reclaim algorithm has been
> modified to make the isolate_lru_pages() as a pluggable component. The
> scan_control data structure now accepts the container on behalf of which
> reclaims are carried out. try_to_free_pages() has been extended to becom
hi,
> diff -puN mm/memory.c~mem-control-accounting mm/memory.c
> --- linux-2.6.22-rc6/mm/memory.c~mem-control-accounting 2007-07-05
> 13:45:18.0 -0700
> +++ linux-2.6.22-rc6-balbir/mm/memory.c 2007-07-05 13:45:18.0
> -0700
> @@ -1731,6 +1736,9 @@ gotten:
>
Hi Andrew,
it seems we've accidentally lost one JBD fix (probably it was my mistake
when rediffing some checkpointing changes) as Kirill has noted. A transaction
can currently be released when there are still some buffers on one of its
checkpointing lists. Attached patch should fix it (it stil
Hello,
On Mon 02-07-07 18:16:09, Kirill Korotaev wrote:
> it looks like the following fix:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=43c3e6f5abdf6acac9b90c86bf03f995bf7d3d92
>
> was lost after resurrecting of the spliced checkpointing list in this patch:
headers_install by default puts headers into usr/include/ .
They're auto-generated, so should be ignored.
Same for *.orig, *.rej .
If you have .orig or .rej files hanging around, it means you
have an unresolved merge conflict. Better not ignore it.
Segher
___
On Tue, 3 Jul 2007, Rusty Russell wrote:
This looks good. The randomness in the hash means we no longer need the
"hit the same hash bucket" heuristic to avoid hashbombing.
I still wonder if we should batch up the drops a little while we're
doing all this work? Should reduce stress under serio
Hi,
On Monday 02 July 2007 18:55, Serge E. Hallyn wrote:
> A list of the people we are currently aware of who are showing interest
> in these features follows. What I'd like to know is, from this list, do
> some people know what general or specific areas they plan to or want to
> work on over the
Paul Menage wrote:
> On 7/10/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
>
>>A (still under construction) list of features we expect to be worked on
>>next year looks like this:
>>4. task containers functionality
>>specific containers
>
>
> A couple of more container s
17 matches
Mail list logo
