On Thu, Jan 21, 2016 at 01:08:18PM -0800, H. Peter Anvin wrote:
>> On 01/21/16 13:03, Yu-cheng Yu wrote:
>> > Hello Leonid,
>> >
>> > You are probably right. Let me check this and get back to you.
>> >
>> > Thanks,
>> > Yu-cheng
>> >
>>
>> The hardware people have gotten back to us and this inc
and similar new
instructions).
In view of above findings we would like to suggest to double check if
disabling AVX together with "eagerfpu off" is actually required and is a
real necessity. It would be helpful to consult with Intel engineers
regarding related design details.
Since
> > There are already locks used inside hrtimer code, so why should users
> > of the hrtimer add another layer of locks and get involved in the
> > intricacy of which cases are protected by internal hrtimer lock and
> > which are not?
>
> Groan. The hrtimer locks are there to protect the internal
Commit-ID: b22affe0aef429d657bc6505aacb1c569340ddd2
Gitweb: http://git.kernel.org/tip/b22affe0aef429d657bc6505aacb1c569340ddd2
Author: Leonid Shatz
AuthorDate: Mon, 4 Feb 2013 14:33:37 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 5 Feb 2013 11:52:41 +0100
hrtimer: Prevent
is to
have kernel more robust. There are already locks used inside hrtimer code,
so why should users of the hrtimer add another layer of locks and get
involved in the intricacy of which cases are protected by internal hrtimer
lock and which are not?
Leonid Shatz
> -Original Message
I assume the race can also happen between hrtimer cancel and start. In both
cases timer base switch can happen.
Izik, please check if you can arrange the patch in the standard format (do
we need to do it against latest kernel version?)
Leonid Shatz
> -Original Message-
> From:
6 matches
Mail list logo