linux-kernel - Re: [PATCH 06/13] block, cfq: misc updates to cfq_io

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:	Thu, 27 Oct 2011 09:24:54 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	axboe@...nel.dk, ctalbott@...gle.com, rni@...gle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/13] block, cfq: misc updates to cfq_io_context

Hello, Vivek.

On Thu, Oct 27, 2011 at 11:39:01AM -0400, Vivek Goyal wrote:
> On Tue, Oct 25, 2011 at 06:48:32PM -0700, Tejun Heo wrote:
> > Make the following changes to prepare for ioc/cic management cleanup.
> > 
> > * Add cic->q so that ioc can determine the associated queue without
> >   querying cfq.  This will eventually replace ->key.
> 
> Not sure what's the advantage of storing cic->q instead of cic->cfqd.
> In blk-ioc code getting to cic's queue becomes easier but then reaching
> to cfqd in cfq code becomes much longer.

It's primarily for API separation.  Currently, io_context and cfq are
intermixed without clear layer of separation.  The optimization of
avoiding one indirect deref at this level isn't worth blurring API
boundaries especially when the cachelines being derefed are known to
be hot (we're deep in elevator path after all).  I'm working on a
patchset to make proper separation between them.  If reducing that one
indrect load proves to be worthwhile (I'm extremely skeptical tho), we
can use another another caching entry in cic.

Thanks.

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