On Mon, 30 Jun 2014 17:43:50 -0400
Jason Baron wrote:
> Hi Steve,
>
> I took a closer look at this, and I'm thinking now that its simpler to
> just take the >i_mutex in sched_feat_write(), surrounding the
> test/set jump_label call. It should be about 3 lines :)
Smaller patches are always
Hi Steve,
I took a closer look at this, and I'm thinking now that its simpler to
just take the >i_mutex in sched_feat_write(), surrounding the
test/set jump_label call. It should be about 3 lines :)
I started re-working this with the patches in this series and it just
seemed like a lot of code
Hi Steve,
I took a closer look at this, and I'm thinking now that its simpler to
just take the inode-i_mutex in sched_feat_write(), surrounding the
test/set jump_label call. It should be about 3 lines :)
I started re-working this with the patches in this series and it just
seemed like a lot of
On Mon, 30 Jun 2014 17:43:50 -0400
Jason Baron jba...@akamai.com wrote:
Hi Steve,
I took a closer look at this, and I'm thinking now that its simpler to
just take the inode-i_mutex in sched_feat_write(), surrounding the
test/set jump_label call. It should be about 3 lines :)
Smaller
On 06/23/2014 10:28 PM, Steven Rostedt wrote:
> Cleaning out my INBOX I found this patch series. It seems to have been
> forgotten about. It ended up with Ingo and Peter agreeing with the way
> things should be done and I thought Jason was going to send an update.
> But that seems to never have
Cleaning out my INBOX I found this patch series. It seems to have been
forgotten about. It ended up with Ingo and Peter agreeing with the way
things should be done and I thought Jason was going to send an update.
But that seems to never have happened.
Does this patch series still look legit?
Cleaning out my INBOX I found this patch series. It seems to have been
forgotten about. It ended up with Ingo and Peter agreeing with the way
things should be done and I thought Jason was going to send an update.
But that seems to never have happened.
Does this patch series still look legit?
On 06/23/2014 10:28 PM, Steven Rostedt wrote:
Cleaning out my INBOX I found this patch series. It seems to have been
forgotten about. It ended up with Ingo and Peter agreeing with the way
things should be done and I thought Jason was going to send an update.
But that seems to never have
* Peter Zijlstra wrote:
> On Mon, Jul 01, 2013 at 12:12:11AM -0400, Jason Baron wrote:
> >
> > Yes, I agree that 'higher' level locking may be required for some callers of
> > the newly proposed interface. However, I do think that the
> > static_key_slow_set_true()/false() provides a nice
On Mon, Jul 01, 2013 at 12:12:11AM -0400, Jason Baron wrote:
>
> Yes, I agree that 'higher' level locking may be required for some callers of
> the newly proposed interface. However, I do think that the
> static_key_slow_set_true()/false() provides a nice abstraction for some
> callers, while
On Mon, Jul 01, 2013 at 12:12:11AM -0400, Jason Baron wrote:
Yes, I agree that 'higher' level locking may be required for some callers of
the newly proposed interface. However, I do think that the
static_key_slow_set_true()/false() provides a nice abstraction for some
callers, while
* Peter Zijlstra pet...@infradead.org wrote:
On Mon, Jul 01, 2013 at 12:12:11AM -0400, Jason Baron wrote:
Yes, I agree that 'higher' level locking may be required for some callers of
the newly proposed interface. However, I do think that the
static_key_slow_set_true()/false() provides
On 06/29/2013 03:20 AM, Ingo Molnar wrote:
* jba...@akamai.com wrote:
Hi,
As pointed out by Andi Kleen, some static key users can be racy because they
check the value of the key->enabled, and then subsequently update the branch
direction. A number of call sites have 'higher' level locking
On 06/29/2013 03:20 AM, Ingo Molnar wrote:
* jba...@akamai.com jba...@akamai.com wrote:
Hi,
As pointed out by Andi Kleen, some static key users can be racy because they
check the value of the key-enabled, and then subsequently update the branch
direction. A number of call sites have 'higher'
* jba...@akamai.com wrote:
> Hi,
>
> As pointed out by Andi Kleen, some static key users can be racy because they
> check the value of the key->enabled, and then subsequently update the branch
> direction. A number of call sites have 'higher' level locking that avoids this
> race, but the
* jba...@akamai.com jba...@akamai.com wrote:
Hi,
As pointed out by Andi Kleen, some static key users can be racy because they
check the value of the key-enabled, and then subsequently update the branch
direction. A number of call sites have 'higher' level locking that avoids this
race,
16 matches
Mail list logo
