[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHGf_=qs+-YZ-XFx5FyWMhF4Dee3_bCGJXGmKkQ0_ED75KxxOQ@mail.gmail.com>
Date: Wed, 11 Jan 2012 14:50:55 -0500
From: KOSAKI Motohiro <kosaki.motohiro@...il.com>
To: Pavel Emelyanov <xemul@...allels.com>
Cc: Cyrill Gorcunov <gorcunov@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Kyle Moffett <kyle@...fetthome.net>, Tejun Heo <tj@...nel.org>,
Glauber Costa <glommer@...allels.com>,
Andi Kleen <andi@...stfloor.org>,
Matt Helsley <matthltc@...ibm.com>,
Pekka Enberg <penberg@...nel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
Vasiliy Kulikov <segoon@...nwall.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Herbert Xu <herbert@...dor.hengli.com.au>,
"David S. Miller" <davem@...emloft.net>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Andrey Vagin <avagin@...nvz.org>
Subject: Re: [RFC] on general object IDs again
> This might work for mm_structs, although quite a lot apps now do have threads and
> this mm->users check will be negative. But how about open files? Once we entered the
> get-the-youngest-file-owner routine we need to take locks and with 1000 tasks the
> overhead is not 1000 syscalls, but 1000 (syscalls + locks).
Unfortunately, I have no knowledge your program have what assumption
of file modify. When I reviewed mincore patch from you, you said you
assume any file are preserved. And If nobody change the files, why do
we need to care file locks? I have no knowledge a grand picture of
your design at all.
--
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/
Powered by blists - more mailing lists