linux-kernel - Re: [RFC] time: xtime

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:	Sat, 07 May 2011 07:02:32 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	john stultz <johnstul@...ibm.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Anton Blanchard <anton@...ba.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC] time: xtime_lock is held too long

Le vendredi 06 mai 2011 à 16:28 -0700, john stultz a écrit :

> Defeating seqlock power? My thoughts are that seqlocks are nice
> lightweight reader/writer locks that avoid writer starvation. You seem
> to be trying to redefine or extend them to be something else which is
> more subtle. 
> 

All I am trying to explain is that a seqlock is a compound of two
things : One spinlock to synchronize writers among themselves, one
seqcount to synchronize readers with a writer.

But the API provides only a compound one. Writer uses the whole locking,
while it would be nice to be able to separate the two steps. Note that
because write_seqlock() and write_sequnlock() are inlined, this would
not increase text size.

One another problem is that spinlock is in same cache line than
seqcount, while a reader doesnt need the spinlock.

> I agree, the code is complex!  I'm just not sure adding more
> complicated/subtle locking mechanisms is a good solution. Instead I'd
> suggest simply splitting up the locks (by using new locks) to reduce the
> amount of data that is being protected by a single lock.
> 
> But again, maybe I'm misunderstanding you?

Adding locks might be fine, I really dont know yet. Its adding yet
another pieces of memory to be dirtied. And total number of cache lines
to be dirtied gives the latency.

I would like to have a ktime_get() service as fast as possible, with
guarded latencies.

Typical workloads need to call it hundred of thousands times per second.

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