* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 17:04 ` Jens Axboe
@ 2012-12-17 17:08 ` Linus Torvalds
2012-12-17 17:09 ` Jens Axboe
2012-12-17 17:15 ` Jeff Moyer
2012-12-17 17:47 ` Tejun Heo
2 siblings, 1 reply; 13+ messages in thread
From: Linus Torvalds @ 2012-12-17 17:08 UTC (permalink / raw)
To: Jens Axboe; +Cc: Tejun Heo, Jeff Moyer, linux-kernel@vger.kernel.org
On Mon, Dec 17, 2012 at 9:04 AM, Jens Axboe <axboe@kernel.dk> wrote:
>
> Linus, how do you want to handle this? I can do a revert and re-send a
> pull.
Well, I already did the pull. Can we just stick in a commit that hides
the API while this gets discussed/fixes?
Linus
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 17:08 ` Linus Torvalds
@ 2012-12-17 17:09 ` Jens Axboe
0 siblings, 0 replies; 13+ messages in thread
From: Jens Axboe @ 2012-12-17 17:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tejun Heo, Jeff Moyer, linux-kernel@vger.kernel.org
On 2012-12-17 18:08, Linus Torvalds wrote:
> On Mon, Dec 17, 2012 at 9:04 AM, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Linus, how do you want to handle this? I can do a revert and re-send a
>> pull.
>
> Well, I already did the pull. Can we just stick in a commit that hides
> the API while this gets discussed/fixes?
Sure, works for me. Then we'll either yank it for 3.8 final, or adopt.
Whatever fits the timeframe.
I'll send you a pull later.
--
Jens Axboe
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 17:04 ` Jens Axboe
2012-12-17 17:08 ` Linus Torvalds
@ 2012-12-17 17:15 ` Jeff Moyer
2012-12-17 19:06 ` Jens Axboe
2012-12-17 17:47 ` Tejun Heo
2 siblings, 1 reply; 13+ messages in thread
From: Jeff Moyer @ 2012-12-17 17:15 UTC (permalink / raw)
To: Jens Axboe; +Cc: Tejun Heo, Linus Torvalds, linux-kernel@vger.kernel.org
Jens Axboe <axboe@kernel.dk> writes:
> On 2012-12-17 18:00, Tejun Heo wrote:
>> On Mon, Dec 17, 2012 at 11:06:39AM -0500, Jeff Moyer wrote:
>>> Jens Axboe <axboe@kernel.dk> writes:
>>>
>>>> - Export control of bdi flusher thread CPU mask and default to using the
>>>> home node (if known) from Jeff.
>>>
>>> I certainly wouldn't mind this going in, but I think Tejun NACKed this
>>> patch. Tejun?
>>
>> Hmm... yeah, I would much prefer if this doesn't go in this time. I
>> think we need something more generic for threadpools w/ scheduling
>> restrictions. It would be possible to retrofit so that the interface
>> eventually matches but given that this feature isn't an immediate
>> must-have thing, I think it would be better to not do this right now.
>
> OK, if you have something generic for threadpools in mind, we can wait
> with this one. I just thought that a "real" interface was nicer than
> manual setting, especially since the flusher threads come and go. Then
> you'd need some udev hook to get it set, not even sure how easy that
> would be with the weird linkage.
>
> Jeff, lets default to the node mask at least. Can you resend a patch
> that doesn't add the API, but just defaults to setting the affinity to
> the cpu mask of the home node?
Well, it turns out that the numa node is always -1, since bdi devices
always have a null parent. I have a patch set to clean that up, but it
depends on my other numa patches in the scsi area that will hopefully
go in 3.9.
> Linus, how do you want to handle this? I can do a revert and re-send a
> pull.
For now, I think it would be cleanest if we just reverted the change.
Cheers,
Jeff
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 17:15 ` Jeff Moyer
@ 2012-12-17 19:06 ` Jens Axboe
2012-12-17 19:27 ` Linus Torvalds
0 siblings, 1 reply; 13+ messages in thread
From: Jens Axboe @ 2012-12-17 19:06 UTC (permalink / raw)
To: Jeff Moyer; +Cc: Tejun Heo, Linus Torvalds, linux-kernel@vger.kernel.org
On 2012-12-17 18:15, Jeff Moyer wrote:
> Jens Axboe <axboe@kernel.dk> writes:
>
>> On 2012-12-17 18:00, Tejun Heo wrote:
>>> On Mon, Dec 17, 2012 at 11:06:39AM -0500, Jeff Moyer wrote:
>>>> Jens Axboe <axboe@kernel.dk> writes:
>>>>
>>>>> - Export control of bdi flusher thread CPU mask and default to using the
>>>>> home node (if known) from Jeff.
>>>>
>>>> I certainly wouldn't mind this going in, but I think Tejun NACKed this
>>>> patch. Tejun?
>>>
>>> Hmm... yeah, I would much prefer if this doesn't go in this time. I
>>> think we need something more generic for threadpools w/ scheduling
>>> restrictions. It would be possible to retrofit so that the interface
>>> eventually matches but given that this feature isn't an immediate
>>> must-have thing, I think it would be better to not do this right now.
>>
>> OK, if you have something generic for threadpools in mind, we can wait
>> with this one. I just thought that a "real" interface was nicer than
>> manual setting, especially since the flusher threads come and go. Then
>> you'd need some udev hook to get it set, not even sure how easy that
>> would be with the weird linkage.
>>
>> Jeff, lets default to the node mask at least. Can you resend a patch
>> that doesn't add the API, but just defaults to setting the affinity to
>> the cpu mask of the home node?
>
> Well, it turns out that the numa node is always -1, since bdi devices
> always have a null parent. I have a patch set to clean that up, but it
> depends on my other numa patches in the scsi area that will hopefully
> go in 3.9.
Sigh, in that case, yes lets just revert it.
--
Jens Axboe
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 19:06 ` Jens Axboe
@ 2012-12-17 19:27 ` Linus Torvalds
2012-12-17 19:28 ` Jens Axboe
0 siblings, 1 reply; 13+ messages in thread
From: Linus Torvalds @ 2012-12-17 19:27 UTC (permalink / raw)
To: Jens Axboe; +Cc: Jeff Moyer, Tejun Heo, linux-kernel@vger.kernel.org
On Mon, Dec 17, 2012 at 11:06 AM, Jens Axboe <axboe@kernel.dk> wrote:
>
> Sigh, in that case, yes lets just revert it.
So just to check - we're talking about commit 8fa72d234da9 ("bdi: add
a user-tunable cpu_list for the bdi flusher threads"). It reverts
cleanly, but I wanted to make sure we're all on the same page..
Linus
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 19:27 ` Linus Torvalds
@ 2012-12-17 19:28 ` Jens Axboe
2012-12-17 19:38 ` Shentino
0 siblings, 1 reply; 13+ messages in thread
From: Jens Axboe @ 2012-12-17 19:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Moyer, Tejun Heo, linux-kernel@vger.kernel.org
On 2012-12-17 20:27, Linus Torvalds wrote:
> On Mon, Dec 17, 2012 at 11:06 AM, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Sigh, in that case, yes lets just revert it.
>
> So just to check - we're talking about commit 8fa72d234da9 ("bdi: add
> a user-tunable cpu_list for the bdi flusher threads"). It reverts
> cleanly, but I wanted to make sure we're all on the same page..
That is the one, revert at will :-)
--
Jens Axboe
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 19:28 ` Jens Axboe
@ 2012-12-17 19:38 ` Shentino
0 siblings, 0 replies; 13+ messages in thread
From: Shentino @ 2012-12-17 19:38 UTC (permalink / raw)
To: Jens Axboe
Cc: Linus Torvalds, Jeff Moyer, Tejun Heo,
linux-kernel@vger.kernel.org
On Mon, Dec 17, 2012 at 11:28 AM, Jens Axboe <axboe@kernel.dk> wrote:
> On 2012-12-17 20:27, Linus Torvalds wrote:
>> On Mon, Dec 17, 2012 at 11:06 AM, Jens Axboe <axboe@kernel.dk> wrote:
>>>
>>> Sigh, in that case, yes lets just revert it.
>>
>> So just to check - we're talking about commit 8fa72d234da9 ("bdi: add
>> a user-tunable cpu_list for the bdi flusher threads"). It reverts
>> cleanly, but I wanted to make sure we're all on the same page..
Page, heh.
> That is the one, revert at will :-)
>
> --
> Jens Axboe
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 17:04 ` Jens Axboe
2012-12-17 17:08 ` Linus Torvalds
2012-12-17 17:15 ` Jeff Moyer
@ 2012-12-17 17:47 ` Tejun Heo
2012-12-17 19:07 ` Jens Axboe
2 siblings, 1 reply; 13+ messages in thread
From: Tejun Heo @ 2012-12-17 17:47 UTC (permalink / raw)
To: Jens Axboe; +Cc: Jeff Moyer, Linus Torvalds, linux-kernel@vger.kernel.org
Hello, Jens.
On Mon, Dec 17, 2012 at 06:04:42PM +0100, Jens Axboe wrote:
> OK, if you have something generic for threadpools in mind, we can wait
> with this one. I just thought that a "real" interface was nicer than
> manual setting, especially since the flusher threads come and go. Then
> you'd need some udev hook to get it set, not even sure how easy that
> would be with the weird linkage.
I've been thinking about this and I think what we really need is a
generic interface for thread pools where the user can specify various
attributes - priority, affinity and probably cgroup association, so
that those attributes are exposed in generic manner while backend
creates and manages worker pools identified by actual attriutes so
that we don't end up with gazillion pools. crypto and writeback would
be the obvious users and probably the virtio too. I'll write more
when things get more concrete.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] core block IO bits for 3.8
2012-12-17 17:47 ` Tejun Heo
@ 2012-12-17 19:07 ` Jens Axboe
0 siblings, 0 replies; 13+ messages in thread
From: Jens Axboe @ 2012-12-17 19:07 UTC (permalink / raw)
To: Tejun Heo; +Cc: Jeff Moyer, Linus Torvalds, linux-kernel@vger.kernel.org
On 2012-12-17 18:47, Tejun Heo wrote:
> Hello, Jens.
>
> On Mon, Dec 17, 2012 at 06:04:42PM +0100, Jens Axboe wrote:
>> OK, if you have something generic for threadpools in mind, we can wait
>> with this one. I just thought that a "real" interface was nicer than
>> manual setting, especially since the flusher threads come and go. Then
>> you'd need some udev hook to get it set, not even sure how easy that
>> would be with the weird linkage.
>
> I've been thinking about this and I think what we really need is a
> generic interface for thread pools where the user can specify various
> attributes - priority, affinity and probably cgroup association, so
> that those attributes are exposed in generic manner while backend
> creates and manages worker pools identified by actual attriutes so
> that we don't end up with gazillion pools. crypto and writeback would
> be the obvious users and probably the virtio too. I'll write more
> when things get more concrete.
I agree. That part of the writeback code is pretty generic
functionality.
So new course of action is to revert the commit, and then I'm sure Jeff
will re-send the code to just set the affinity to something sane by
default when that is easily doable.
--
Jens Axboe
^ permalink raw reply [flat|nested] 13+ messages in thread