linux-kernel - Re: [PATCH 3/3] ide: use per-device request queue locks

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] [day] [month] [year] [list]

Message-ID: <87myeu5wfq.fsf@denkblock.local>
Date:	Wed, 17 Dec 2008 22:22:17 +0100
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] ide: use per-device request queue locks

Elias Oltmanns <eo@...ensachen.de> wrote:
> Bartlomiej Zolnierkiewicz <bzolnier@...il.com> wrote:
>> On Monday 24 November 2008, Elias Oltmanns wrote:
[...]
>>> Finally, some more general blathering on the topic at hand: A while ago,
>>> I spent some thought on the possibilities of giving the block layer a
>>> notion of linked device queues as an equivalent hwgroups in ide,
>>> scsi_hosts or ata_ports and let it take care of time / bandwidth
>>> distribution among the queues belonging to one group. This is, as I
>>> understand, pretty much what your code is relying on since you have
>>> chucked out choose_drive(). However, this turned out not to be too easy
>>
>> This is the right way to go and I has always advocated for it.  However
>> after seeing how libata got away with ignoring the issue altogether
>> I'm no longer sure of this.  I haven't seen any bug reports which would
>> indicate that simplified approach has any really negative consequences.
>
> Well, libata can safely ignore it since scsi takes care of that (see
> scsi_run_queue() which is called on command completion).
>
>>
>> [ Still would be great to have the control over bandwitch of "queue-group"
>>   at the block layer level since we could also use it for distributing the
>>   available PCI[-E] bus bandwitch. ]
>>
>>> and I'm not quite sure whether we really want to go down that road. One
>>> major problem is that there is no straight forward way for the block
>>> layer to know, whether a ->request_fn() has actually taken a request off
>>> the queue and if not (or less than queue_depth anyway), whether it's
>>> just the device that couldn't take any more or the controller instead.
>>> On the whole, it seems not exactly trivial to get it right and it would
>>> probably be a good idea to consult Jens and perhaps James before
>>
>> I think that having more information returned by ->request_fn() could be
>> beneficial to the block layer (independently whether we end up adding
>> support for "queue-groups" to the block layer or not) but this definitely
>> needs to be verified with Jens & James.
>
> Some time back, I raised this with Jens in connection with your previous
> version of the patchset [1]. I didn't get an answer at the time but
> perhaps it would help to raise it again in its own right and to give
> some more examples of its potential merits.

[1] http://marc.info/?l=linux-ide&m=122470007616121&w=2

What ever does it mean that I missed something vital in this email too?
;-)

Regards,

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