linux-kernel - Re: [PATCH 0/4] ipc/sem.c: Alternative to Nick's patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 16 Aug 2009 07:01:17 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Manfred Spraul <manfred@...orfullife.com>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nadia Derbey <Nadia.Derbey@...l.net>,
	Pierre Peiffer <peifferp@...il.com>
Subject: Re: [PATCH 0/4] ipc/sem.c: Alternative to Nick's patch

On Sat, Aug 15, 2009 at 11:57:12PM +0200, Manfred Spraul wrote:
> The following series of 4 patches are an alternative to Nick's 4th
> patch. They are intended to be applied after the first 3 patches from
> Nick.
> 
> The advantages are simple:
> - Lower number of new code lines.
> - Lower total code size increase.

Look, I just think these are not a good advantage, because the
complex queue and algorithm is nasty to use for simple ops. I
don't think it is an advantage to make simple op processing
more complex just so it fits in the existing complex op processing.

> - Lower runtime memory consumption.

I'll fix this.

> - 4 simple patches with the individual changes, each one can be
>   reviewed individually.

I don't really get this. Was my patch hard to review?

> - Lower number of seperate codepaths.

As I said, I don't think this is such an advantage. The disadvantage
is that you make the already complex path more complex, wheras I just
add a simpler path. So.

> The disadvantage is also clear:
> My patch doesn't optimize wait-for-zero as good as Nick's patch.
> For example:
> * n wait-for-zero entries and one decrement by 2 to be woken up,
>   semval at 1, an increment by 2 arrives:
>     Nick's patch is O(1) and my patch is O(n).
> 
> Neither of us knows if anyone uses that scenario and there are other
> codepaths that are O(n^2), too. Thus I don't think this is a big issue.
> 
> Below is the test app/benchmark app I used:
> The present kernel breaks down if lots of tasks are sleeping on the same
> semaphore array, with the patch, the breakdown disappears.
> 
> With my test app, the performance of Nick's and my patch are comparable.

This app is pretty similar to mine.

--
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/