linux-kernel - Re: [GIT PULL] core block IO bits for 3.8

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Dec 2012 12:15:01 -0500
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] core block IO bits for 3.8

Jens Axboe <axboe@...nel.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@...nel.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
--
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/