Thread (12 messages) 12 messages, 5 authors, 2019-09-21

Re: [PATCH 2/2] block, bfq: delete "bfq" prefix from cgroup filenames

From: Jens Axboe <axboe@kernel.dk>
Date: 2019-09-20 13:05:11
Also in: cgroups, lkml

On 9/20/19 12:58 AM, Paolo Valente wrote:
quoted
Il giorno 18 set 2019, alle ore 18:19, Paolo Valente [off-list ref] ha scritto:


quoted
Il giorno 18 set 2019, alle ore 17:19, Tejun Heo [off-list ref] ha scritto:

Hello,

On Wed, Sep 18, 2019 at 07:18:50AM +0200, Paolo Valente wrote:
quoted
A solution that both fulfills userspace request and doesn't break
anything for hypothetical users of the current interface already made
it to mainline, and Linus liked it too.  It is:
Linus didn't like it.  The implementation was a bit nasty.  That was
why it became a subject in the first place.
quoted
19e9da9e86c4 ("block, bfq: add weight symlink to the bfq.weight cgroup parameter")

But it was then reverted on Tejun's request to do exactly what we
don't want do any longer now:
cf8929885de3 ("cgroup/bfq: revert bfq.weight symlink change")
Note that the interface was wrong at the time too.
quoted
So, Jens, Tejun, can we please just revert that revert?
I think presenting both io.weight and io.bfq.weight interfaces are
probably the best course of action at this point but why does it have
to be a symlink?  What's wrong with just creating another file with
the same backing function?
I think a symlink would be much clearer for users, given the confusion
already caused by two names for the same parameter.  But let's hear
others' opinion too.
Jens, could you express your opinion on this?  Any solution you and
Tejun agree on is ok for me.  Also this new (fourth) possible
implementation of this fix, provided that then it is definitely ok for
both of you.
Retaining both interfaces is arguably the right solution. It would be
nice if we didn't have to, but the first bfq variant was incompatible
with the in-kernel one, so we'll always have that out in the wild.
Adding everything to stable doesn't work, as we still have existing
kernels out there with the interface. In fact, in some ways that's
worse, as you definitely don't want interfaces to change between two
stable kernels.

I know it's not ideal, and some better initial planning would have
made it better, but we have to deal with the situation as it stands
now.

-- 
Jens Axboe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help