linux-kernel - Re: [PATCH] time : SMP friendly alignment of struct clocksource

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]

Message-Id: <1174415881.17430.21.camel@localhost>
Date:	Tue, 20 Mar 2007 11:38:01 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	Eric Dumazet <dada1@...mosbay.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] time : SMP friendly alignment of struct clocksource

On Tue, 2007-03-20 at 11:04 -0700, Daniel Walker wrote:
> On Tue, 2007-03-20 at 10:58 -0700, john stultz wrote:
> 
> > >  	/* timekeeping specific data, ignore */
> > > -	cycle_t cycle_last, cycle_interval;
> > > -	u64 xtime_nsec, xtime_interval;
> > > +	cycle_t cycle_interval;
> > > +	u64	xtime_interval;
> > > +	/*
> > > +	 * Second part is written at each timer interrupt
> > > +	 * Keep it in a different cache line to dirty no
> > > +	 * more than one cache line.
> > > +	 */
> > > +	cycle_t cycle_last ____cacheline_aligned_in_smp;
> > > +	u64 xtime_nsec;
> > >  	s64 error;
> 
> What was the motivation for having these (cycle_last for example) in the
> clocksource structure. I recall them being added in there at one point,
> but I'm not sure why.. Specifically the ones that are updated often.

Roman claimed it produced better code, and the values are functionally
clocksource specific (meaning if the clocksource changed, and they were
global, you would have to reset them anyway).

I think logically those values are more timekeeping oriented then
clocksource oriented, but one could argue that since we manipulate
clocksource.mult in the timekeeping's NTP code, mult is timekeeping
specific as well.

If you really wanted a clean design, you'd probably have to keep all of
those values as a timekeeping_clocksource struct, and then have smaller
clocksource structs (name, mult, shift, read) that is filled in by the
clocksource driver and copied over on clocksource changes. That way the
timekeeping code wouldn't manipulate the clocksource structure directly.

But really, it seems like work for little to no reward (plus opens the
issue of "but i want a ntp frequency adjusted sched_clock!" which would
not be possible).

-john

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