public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Davide Libenzi <davidel@xmailserver.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ulrich Drepper <drepper@redhat.com>
Subject: Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core
Date: Mon, 4 Jun 2007 16:12:35 +0200	[thread overview]
Message-ID: <20070604141235.GA24352@elte.hu> (raw)
In-Reply-To: <20070604152540.985c186a.dada1@cosmosbay.com>


* Eric Dumazet <dada1@cosmosbay.com> 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 or two, instead of lecturing him about O(1) ...

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 have blown up the complexity of the functions for 
no good reason - instead of neatly separating them out. You have added 
_33_ (thirty-three!) new 'if' branches to futex.c! The feature you 
introduced is nice and useful, but for heaven's sake please work on 
cleanliness of your code some more and undo that colossal damage ... 
preferably before working on other areas of the kernel.

> O(128) is still O(1) for instance. Having to search a bit in a PAGE is 
> a sensible compromise, if we dont add overhead on each fget() calls.

hm, i'm not sure what you are talking about here. Look at Davide's stuff 
- it's clearly not O(128)...

> You add conditional branches on very hot spots.
>
> When you open/close a file, you need to access previous and next 
> cells, so you need 3 cache lines, exactly like current *legacy* code. 
> (one for file pointer, one on each bitmap flags(open/close_on_exec) )

the fd spaces will be separated _no matter what_, that is a physical 
inevitability of the ABI in question. Whether you hide that into 'extra 
complexity by trying to bend bitmaps in a way that the new users dont 
need' or do it explicitly like Davide, i'll go for the explicit 
separation. Davide's approach, besides being cleaner, simpler and faster 
also has the advantage of enabling the possible demoting of the 'legacy' 
fd space in the future. Or demoting the 'new' fd space in the future, if 
the interface does not take off.

	Ingo

  parent reply	other threads:[~2007-06-04 14:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-02 22:59 [patch 1/2] ufd v1 - unsequential O(1) fdmap core Davide Libenzi
2007-06-03 21:19 ` Eric Dumazet
2007-06-03 22:51   ` Davide Libenzi
2007-06-04  6:08     ` Andrew Morton
2007-06-04  8:05       ` Ingo Molnar
2007-06-04  8:09         ` Ingo Molnar
2007-06-04  8:34           ` Andrew Morton
2007-06-04  8:42             ` Ingo Molnar
2007-06-04  8:47               ` Andrew Morton
2007-06-04 13:05                 ` Davide Libenzi
2007-06-04 13:30                   ` Davide Libenzi
2007-06-04 16:56                   ` Andrew Morton
2007-06-04 17:57                     ` Davide Libenzi
2007-06-04 10:28             ` Eric Dumazet
2007-06-04 12:55               ` Davide Libenzi
2007-06-04 13:25                 ` Eric Dumazet
2007-06-04 13:33                   ` Davide Libenzi
2007-06-04 13:35                   ` Davide Libenzi
2007-06-04 14:28                     ` Eric Dumazet
2007-06-04 14:53                       ` Davide Libenzi
2007-06-04 14:12                   ` Ingo Molnar [this message]
2007-06-04 14:27                     ` Eric Dumazet
2007-06-05 20:37                       ` Ingo Molnar
2007-06-05 20:50                         ` Thomas Gleixner
2007-06-05 20:57                         ` Eric Dumazet
2007-06-05 22:29                         ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070604141235.GA24352@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=davidel@xmailserver.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox