[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090814085841.GF32342@wotan.suse.de>
Date: Fri, 14 Aug 2009 10:58:41 +0200
From: Nick Piggin <npiggin@...e.de>
To: Manfred Spraul <manfred@...orfullife.com>
Cc: Zach Brown <zach.brown@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Nadia Derbey <Nadia.Derbey@...l.net>,
Pierre Peiffer <peifferp@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [patch 4/4] ipc: sem optimise simple operations
On Wed, Aug 12, 2009 at 08:35:56PM +0200, Manfred Spraul wrote:
> On 08/12/2009 06:07 AM, Nick Piggin wrote:
> >A semaphore set with 250 will use 2K before, and 10K afterward. I
> >don't know that it is a huge amount really, given that they also
> >have to presumably be *protecting* stuff.
> >
> >
> The allocation uses vmalloc for larger allocations, thus 10k should not
> be an issue.
> >We can convert them to hlists (I was going to send a patch to do
> >everything in hlists, but hlists are missing some _rcu variants...
> >maybe I should just convert the pending lists to start with).
> >
> >
> Is it possible to use list_add and list_add_tail instead?
> Add the "waiting for zero" to the beginning and "waiting for nonzero" to
> the end.
The only problem with this is that it means we have to walk
through the list of wait-for-zero for every increment operation,
before getting to the list of negative ops.
The wait-for-zero list should be empty in the case of simple modify
operations which are strictly +1/-1 I guess though.
I do like how it cleanly splits the modify and non-modify operations
though. But if you feel strongly about saving the sapce, I will
do as you suggest.
Thanks,
Nick
--
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