linux-kernel - Re: [PATCH, RFC] block: use a separate plug list for blk-mq requests

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:	Sun, 6 Oct 2013 12:15:08 -0600
From:	Jens Axboe <axboe@...nel.dk>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH, RFC] block: use a separate plug list for blk-mq requests

On Sun, Oct 06 2013, Christoph Hellwig wrote:
> blk_flush_plug_list became a bit of a mess with the introduction of blk-mq,
> so I started looking into separating the blk-mq handling from it.  Turns
> out that by doing this we can streamline the blk-mq submission path a lot.
> 
> If we branch out to a blk-mq specific code path early we can do the list sort
> based on the hw ctx instead of the queue and thus avoid the later improvised
> loop to sort again.  In addition we can also remove the hw irq disabling in
> the submission path entirely and collapse a couple of functions in blk-mq.c,
> all at the cost of an additional list_head in struct blk_plug which can go
> away again as soon as we remove old-school request_fn based drivers.

Thanks, I'll take a look at this. The plugging was done mostly hacky
when implementing it, it was meant to be revisited. So definitely room
for improvement there.

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