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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 17 Dec 2012 20:06:29 +0100
From:	Jens Axboe <axboe@...nel.dk>
To:	Jeff Moyer <jmoyer@...hat.com>
CC:	Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] core block IO bits for 3.8

On 2012-12-17 18:15, Jeff Moyer wrote:
> 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.

Sigh, in that case, yes lets just revert it.

-- 
Jens Axboe

--
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/