linux-kernel - Re: [PATCH] U300 sched

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:	Wed, 8 Jul 2009 18:35:06 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Linus Walleij <linus.ml.walleij@...il.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Peter Zijlstra <peterz@...radead.org>,
	Tim Bird <tim.bird@...sony.com>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [PATCH] U300 sched_clock implementation

On Tue, Jul 07, 2009 at 10:01:58AM +0200, Linus Walleij wrote:
> Adding in Paul M since it was his patch that was supposed to fix up a
> generic solution...
> 
> 2009/7/7 Russell King - ARM Linux <linux@....linux.org.uk>:
> > On Tue, Jun 02, 2009 at 11:00:12AM +0200, Peter Zijlstra wrote:
> >> I think its best if we continue with the patch Paul Mundt has been
> >> proposing.
> >
> > [added Tim Bird to CC]
> >
> > So what do we do? ?There's apparantly been zero movement on this for
> > over a month, and Tim Bird is reposting his patch adding __notrace
> > to ARMs existing sched_clock implementations.
> >
> > Given that it seems the generic approach has died a death, I suggest we
> > merge Linus' U300 patch, and get Tim to redo his patch to take account
> > of that, and apply both.
> >
> > Then, if the generic approach eventually happens, everything can then be
> > fixed up.
> >
> > Alternatively, if there is movement on the generic approach...
> >
> > Discuss.
> >
> 
> I would really like to see Pauls work finalized, it looked very promising,
> and I think there was actually a rough consensus about his last patch.
> But I guess that will be in the 2.6.32 merge window earliest?
> 
There was a consensus up until the point John noted that sched_clock()
can't wrap, so the generic approach is going to need a bit more work to
take the cycle shift and so on in to account. I've gotten momentarily
sidetracked with other things, but I'll post an updated version shortly.

Having said that, I don't see any reason why this should block progress
on the ARM side, once folks are happy with the generic version then most
of the implementations can be killed off, so a few more isn't going to
make much of a difference one way or the other.

The only reason I haven't done an SH-specific sched_clock() is because
none of our clocksources are architecture specific, and they all reside
in drivers/.
--
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/