linux-kernel - Re: [PATCH 11/23] clocksource: atomic signals

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:	Wed, 31 Jan 2007 07:59:45 -0800
From:	Daniel Walker <dwalker@...sta.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org, johnstul@...ibm.com
Subject: Re: [PATCH 11/23] clocksource: atomic signals

On Wed, 2007-01-31 at 12:07 +0100, Ingo Molnar wrote:
> * Daniel Walker <dwalker@...sta.com> wrote:
> 
> > Modifies the way clocks are switched to in the timekeeping code. The 
> > original code would constantly monitor the clocksource list checking 
> > for newly added clocksources. I modified this by using atomic types to 
> > signal when a new clock is added. This allows the operation to be used 
> > only when it's needed.
> 
> I see little difference between your and John's code: both poll 
> something - you poll an atomic "did a new clocksource arrive" flag in 
> the timer interrupt, John takes the clocksource_lock spinlock and checks 
> a "did a new clocksource arrive" variable. Both are global atomic 
> variables in essence.

The original version has more operations on every timer interrupt. Also
changing the spinlock to an atomic eliminates the possibility of
contention in the timer interrupt ..

> what i'd see as a real cleanup here would be to get away from this 'poll 
> whether there's any clocksource update' model, and to just ensure that a 
> running timer irq will always see the latest clocksource. I.e. to run 
> the change_clocksource() logic (and the following updates) when a new 
> clock source is selected - not when the next timer interrupt runs. That 
> would propagate all effects of a new clock source immediately.

You could reduce the code in the interrupt handler (which is good), but
I think you'll end up with a polling model regardless.. If you add some
locking between the interrupt handler and something else you may as well
add the run time of that new critical section to the timer latency . So
I'm not sure it would be a outright win ..

Daniel

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