linux-kernel - Re: [PATCH v6 2/2] Output stall data in debugfs

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Aug 2011 22:23:43 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alex Neronskiy <zakmagnus@...omium.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Don Zickus <dzickus@...hat.com>,
	Mandeep Singh Baines <msb@...omium.org>
Subject: Re: [PATCH v6 2/2] Output stall data in debugfs

On Thu, 2011-08-11 at 13:10 -0700, Alex Neronskiy wrote:
> 
> Another change is to allow concurrent writers. The readers are
> serialized but the writers are concurrent; isn't that a strange
> design? The way the "main" index is changed also looks problematic. A
> writer will switch the index before anything useful is even known to
> be in the buffer, and then a reader can go ahead and get that lock and
> read something potentially very old and misleading. I don't think
> that's okay. 

Ah, right, yeah, stick another lock in there.. One does worry about the
whole writer concurrency thing though, isn't it likely all cpus will
tickle the thing in quick succession? Putting a global lock in that path
isn't good,.. always think of the poor sod with the 4096 cpu machine.

Also, is all of this really useful? The hardlockup watchdog is useful
when you mess up bad, but other than that I've never found it to be
useful at all.

I mean, we're at the point where a PREEMPT=y kernel has a pretty decent
latency and the PREEMPT_RT kernels live at ~30us. So wth are you
measuring?
--
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/