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

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 frequently used
> (and current code is O(N) too).
> Like the "struct fdtable", the unsequential fdmap is RCU friendly too.
> 
> 
> 

Could you please provide a diffstat ?

Me think : "Huge patch, and icache pressure for what exact gain ?"

File descriptor allocation is dust compared to socket setup costs and network 
stuf. (Not speaking of close() wich is O(1) obviously)

If we want a different file descriptor allocation, why should we use a 
parallel structure, and adding one level of complexity ?

Instead of finding the first zero bit in a bitmap, we could just use a cyclic 
allocation, ie finding a zero bit from a 'last' position. Keeping fd_count 
would help not atempting a findzerobit in the case all bits are known to be set.



  reply	other threads:[~2007-06-03 21:19 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 [this message]
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
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=46633047.1020707@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=akpm@linux-foundation.org \
    --cc=davidel@xmailserver.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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