Ingo Molnar a écrit :
no, i just wanted to make a demonstration that one can be pretty nasty
in on-lkml replies while being technically correct :-) I think you went
a bit overboard in your replies to Davide. Lets move this back into
constructive channels, ok? :)
In any case, here is one pre
Ingo Molnar a écrit :
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
For example, the recent futex.c changes you did in commit 34f01cc1
are, and unfortunately there's no better word i can find: plain
disgusting. You apparently have plopped the 'fshared' code into the
existing logic via conditional
On Tue, 2007-06-05 at 22:37 +0200, Ingo Molnar wrote:
> * Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > > For example, the recent futex.c changes you did in commit 34f01cc1
> > > are, and unfortunately there's no better word i can find: plain
> > > disgusting. You apparently have plopped the 'fs
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
> > For example, the recent futex.c changes you did in commit 34f01cc1
> > are, and unfortunately there's no better word i can find: plain
> > disgusting. You apparently have plopped the 'fshared' code into the
> > existing logic via conditionals and h
On Mon, 4 Jun 2007, Andrew Morton wrote:
> > must be RCU friendly (proper barriers) since it's used in
> > lockless code,
>
> Haven't looked at that.
>
> > and must have flags associated to an allocation.
>
> Don't understand that.
It needs to be able to store flags (like close-on-exec, and m
On Mon, 4 Jun 2007 06:05:22 -0700 (PDT) Davide Libenzi <[EMAIL PROTECTED]>
wrote:
> On Mon, 4 Jun 2007, Andrew Morton wrote:
>
> > a) Were IDR trees evaluated and if so, why were they rejected?
> >
> > b) it's a bit disappointing that this new allocator is only usable for
> >one specific ap
On Mon, 4 Jun 2007, Eric Dumazet wrote:
> On Mon, 4 Jun 2007 06:35:16 -0700 (PDT)
> Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 4 Jun 2007, Eric Dumazet wrote:
> >
> > > You add conditional branches on very hot spots.
> >
> > Keep BS for the ones you argue usually, and that are not
On Mon, 4 Jun 2007 06:35:16 -0700 (PDT)
Davide Libenzi <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Jun 2007, Eric Dumazet wrote:
>
> > You add conditional branches on very hot spots.
>
> Keep BS for the ones you argue usually, and that are not able to reply.
> You *still* two bitmaps, because allocat
On Mon, 4 Jun 2007 16:12:35 +0200
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > O(1) lookup doesnt imply it needs to be super-fast. You make a
> > confusion about this.
>
> Davide has written many good speedups for the kernel and he is one of
> the
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
> O(1) lookup doesnt imply it needs to be super-fast. You make a
> confusion about this.
Davide has written many good speedups for the kernel and he is one of
the best scalability experts the Linux kernel has today. You could learn
from Davide a thing
On Mon, 4 Jun 2007, Eric Dumazet wrote:
> You add conditional branches on very hot spots.
Keep BS for the ones you argue usually, and that are not able to reply.
You *still* two bitmaps, because allocation spaces are far apart. So the
"if" will still be there.
- Davide
-
To unsubscribe from
On Mon, 4 Jun 2007, Eric Dumazet wrote:
> Bitmaps are already there, you didnt zap them.
>
> Your proposal is going to double size taken by file table, since you need two
> long words
> per file instead of one pointer.
>
> You add conditional branches on very hot spots.
>
> When you open/close
On Mon, 4 Jun 2007, Davide Libenzi wrote:
> On Mon, 4 Jun 2007, Andrew Morton wrote:
>
> > a) Were IDR trees evaluated and if so, why were they rejected?
> >
> > b) it's a bit disappointing that this new allocator is only usable for
> >one specific application. We have a *lot* of places in
On Mon, 4 Jun 2007 05:55:42 -0700 (PDT)
Davide Libenzi <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Jun 2007, Eric Dumazet wrote:
>
> > Goals :
> > 1) libc wants 'private fds'
> > 2) Latencies of get_unused_fd() for huge processes (more than 100.000 file
> > handles)
> >
> > Point 1) can use a top-do
On Mon, 4 Jun 2007, Andrew Morton wrote:
> a) Were IDR trees evaluated and if so, why were they rejected?
>
> b) it's a bit disappointing that this new allocator is only usable for
>one specific application. We have a *lot* of places in the kernel which
>want allocators of this type. Ma
On Mon, 4 Jun 2007, Eric Dumazet wrote:
> Goals :
> 1) libc wants 'private fds'
> 2) Latencies of get_unused_fd() for huge processes (more than 100.000 file
> handles)
>
> Point 1) can use a top-down allocation, or use a 'last unused' index.
>
>
> Point 2) Instead of introducing a *complex* la
On Mon, 4 Jun 2007 01:34:49 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Jun 2007 10:09:41 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > i think this sums it up:
> > >
> > > http://www.uwsg.iu.edu/hypermail/linux/kernel
On Mon, 4 Jun 2007 10:42:27 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > If we just want some pseudo-private fd space for glibc to use then I'd
> > have thought that the existing code could be tweaked to do that:
> > top-down allocation, sta
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> If we just want some pseudo-private fd space for glibc to use then I'd
> have thought that the existing code could be tweaked to do that:
> top-down allocation, start at some high offset, etc. But apparently
> there's more to it than this.
top-dow
On Mon, 4 Jun 2007 10:09:41 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i think this sums it up:
> >
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2490.html
>
> i mean this mail started it:
>
> http://linux.derkeiler.com/Mailin
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i think this sums it up:
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2490.html
i mean this mail started it:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg13070.html
> and some more, with a benchmark as well:
>
> http://
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> I must say that it's not really clear to me why this fdmap thing was
> created. Exactly what problem is it solving, and what properties is
> it designed to have?
>
> Could not a (prehaps suitably modified) IDR tree have adequately
> provided those
On Sun, 3 Jun 2007 15:51:13 -0700 (PDT) Davide Libenzi <[EMAIL PROTECTED]>
wrote:
> A bitmap allocator made sense because it has the property of making
> allocations compact. Once that requirement is relaxed, it does not make
> any sense to use it (and you have still to modify it in any case).
On Sun, 3 Jun 2007, Eric Dumazet wrote:
> Davide Libenzi a ?crit :
> > Core code for the unsequential fdmap implementation. Random allocation,
> > exact allocation, de-allocation and lookup are all O(1) operations.
> > The only operation that is O(N) is the strict from-N-up kind of allocation,
> >
Davide Libenzi a écrit :
Core code for the unsequential fdmap implementation. Random allocation,
exact allocation, de-allocation and lookup are all O(1) operations.
The only operation that is O(N) is the strict from-N-up kind of allocation,
but that only used by F_DUPFD and it's definitely not fr
Core code for the unsequential fdmap implementation. Random allocation,
exact allocation, de-allocation and lookup are all O(1) operations.
The only operation that is O(N) is the strict from-N-up kind of allocation,
but that only used by F_DUPFD and it's definitely not frequently used
(and current
26 matches
Mail list logo
