linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Kent Overstreet <kmo@daterainc.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Fengguang Wu <fengguang.wu@intel.com>
Subject: Re: [PATCH] idr: Document ida tree sections
Date: Tue, 13 Aug 2013 19:22:11 -0400	[thread overview]
Message-ID: <20130813232211.GI28996@mtj.dyndns.org> (raw)
In-Reply-To: <20130813225927.GA2000@kmo-pixel>

Hello,

On Tue, Aug 13, 2013 at 03:59:27PM -0700, Kent Overstreet wrote:
> > Well, it's not necessarily about requiring it but more about surviving
> > it with some grace when things don't go as expected, which is an
> > important characteristic for common library stuff.
> 
> The patch I posted should solve the high order allocations stuff, and
> sparseness from cyclic allocations was already solved.

I don't know.  Yeah, using vmalloc would be able to work around the
issue for most cases, I suppose.  It's iffy to consume vmalloc space
from ida, which functionally is such a basic algorithmic construct.
It probably won't worsen things noticeably but vmalloc area can be a
very precious resource on 32bit configs.

> Whatever caching optimizations you do with a radix tree version I could
> apply to this bitmap tree version, and my bitmap tree code is simpler
> and _considerably_ faster than the existing code.

But the difference won't really matter.  Cached performance would be
the same and that's likely to cover most cases, right?  It's not like
radix tree is orders of magnitude slower.

Thanks.

-- 
tejun

  reply	other threads:[~2013-08-13 23:22 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-07 17:34 IDA/IDR rewrite, percpu ida Kent Overstreet
2013-08-07 17:34 ` [PATCH 03/10] idr: Rewrite ida Kent Overstreet
2013-08-07 20:22   ` Tejun Heo
2013-08-07 20:51     ` [PATCH] idr: Document ida tree sections Kent Overstreet
2013-08-09 14:57       ` Tejun Heo
2013-08-13 22:13         ` Kent Overstreet
2013-08-13 22:19           ` Tejun Heo
2013-08-13 22:27             ` Kent Overstreet
2013-08-13 22:44               ` Tejun Heo
2013-08-13 22:59                 ` Kent Overstreet
2013-08-13 23:22                   ` Tejun Heo [this message]
2013-08-13 23:51                     ` Kent Overstreet
2013-08-13 23:59                       ` Tejun Heo
2013-08-15  0:04                         ` Kent Overstreet
2013-08-15  0:22                           ` Tejun Heo
2013-08-13 22:33         ` Kent Overstreet
2013-08-07 17:34 ` [PATCH 04/10] idr: Percpu ida Kent Overstreet
2013-08-07 17:56   ` Christoph Lameter
2013-08-07 18:33     ` Kent Overstreet
2013-08-07 19:40       ` Christoph Lameter
2013-08-07 19:57         ` [PATCH] idr: Use this_cpu_ptr() for percpu_ida Kent Overstreet
2013-08-08 14:32           ` Christoph Lameter
2013-08-20 21:19             ` Nicholas A. Bellinger
2013-08-20 21:29               ` Andrew Morton
2013-08-21  2:01                 ` Kent Overstreet
2013-08-21  2:07                   ` Tejun Heo
2013-08-21  2:31                     ` Kent Overstreet
2013-08-21 11:59                       ` Tejun Heo
2013-08-21 21:09                         ` Kent Overstreet
2013-08-21 21:16                           ` Tejun Heo
2013-08-21 21:24                             ` Kent Overstreet
2013-08-21 21:31                               ` Tejun Heo
2013-08-21 14:32               ` Christoph Lameter
2013-08-21 17:49                 ` Nicholas A. Bellinger
2013-08-21 20:49                 ` Andrew Morton
2013-08-22 16:44                   ` Christoph Lameter
2013-08-22 16:56                     ` Jens Axboe
2013-08-07 17:46 ` [PATCH 05/10] idr: Kill old deprecated idr interfaces Kent Overstreet
2013-08-07 17:46 ` [PATCH 06/10] idr: Rename idr_get_next() -> idr_find_next() Kent Overstreet
2013-08-07 17:46 ` [PATCH 08/10] idr: Reimplement idr on top of ida/radix trees Kent Overstreet

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=20130813232211.GI28996@mtj.dyndns.org \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=kmo@daterainc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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;
as well as URLs for NNTP newsgroup(s).