linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ipi_redirect vs rq_affinity
@ 2014-01-24 13:22 Christoph Hellwig
  2014-01-24 19:11 ` Jens Axboe
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2014-01-24 13:22 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-kernel

Hi Jens,

it seems like blk-mq uses the ipi_redirect attribute in pretty much the
same way as the old blk-softirq code used the rq_affinity one, except
that the old code has an additional option to direct into any core in
the current package.

Is there any good reason to not reuse the old name and semantics?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ipi_redirect vs rq_affinity
  2014-01-24 13:22 ipi_redirect vs rq_affinity Christoph Hellwig
@ 2014-01-24 19:11 ` Jens Axboe
  2014-01-27  7:51   ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Jens Axboe @ 2014-01-24 19:11 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel

On Fri, Jan 24 2014, Christoph Hellwig wrote:
> Hi Jens,
> 
> it seems like blk-mq uses the ipi_redirect attribute in pretty much the
> same way as the old blk-softirq code used the rq_affinity one, except
> that the old code has an additional option to direct into any core in
> the current package.
> 
> Is there any good reason to not reuse the old name and semantics?

It is pretty much the same. I don't like the semantics of the old one,
where it's 0/1/2 for off/on/different-on, though. Seems like now would
be a good time to clean it up.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ipi_redirect vs rq_affinity
  2014-01-24 19:11 ` Jens Axboe
@ 2014-01-27  7:51   ` Christoph Hellwig
  2014-01-27 19:16     ` Jens Axboe
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2014-01-27  7:51 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-kernel

On Fri, Jan 24, 2014 at 11:11:29AM -0800, Jens Axboe wrote:
> It is pretty much the same. I don't like the semantics of the old one,
> where it's 0/1/2 for off/on/different-on, though. Seems like now would
> be a good time to clean it up.

I don't think arbitrarily breaking this fairly widely used interface
when a driver is moving to blk-mq sounds like a good idea.  Maybe we
should allow for setting descriptive strings as well?

Also the different on semantics do matter for some use cases, and we
should support both for blk-mq.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ipi_redirect vs rq_affinity
  2014-01-27  7:51   ` Christoph Hellwig
@ 2014-01-27 19:16     ` Jens Axboe
  0 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2014-01-27 19:16 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel

On Sun, Jan 26 2014, Christoph Hellwig wrote:
> On Fri, Jan 24, 2014 at 11:11:29AM -0800, Jens Axboe wrote:
> > It is pretty much the same. I don't like the semantics of the old one,
> > where it's 0/1/2 for off/on/different-on, though. Seems like now would
> > be a good time to clean it up.
> 
> I don't think arbitrarily breaking this fairly widely used interface
> when a driver is moving to blk-mq sounds like a good idea.  Maybe we
> should allow for setting descriptive strings as well?

Yeah, that's a good idea. We could retain the 0/1/2 for compat reasons,
but have it present strings instead.

> Also the different on semantics do matter for some use cases, and we
> should support both for blk-mq.

Certainly, not disagreeing with that.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-01-27 19:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-24 13:22 ipi_redirect vs rq_affinity Christoph Hellwig
2014-01-24 19:11 ` Jens Axboe
2014-01-27  7:51   ` Christoph Hellwig
2014-01-27 19:16     ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).