From: Jens Axboe <axboe@kernel.dk>
To: "Reshetova, Elena" <elena.reshetova@intel.com>,
Eric Biggers <ebiggers3@gmail.com>,
Kees Cook <keescook@chromium.org>
Cc: Christoph Hellwig <hch@infradead.org>,
"james.bottomley@hansenpartnership.com"
<james.bottomley@hansenpartnership.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"fujita.tomonori@lab.ntt.co.jp" <fujita.tomonori@lab.ntt.co.jp>,
"mingo@redhat.com" <mingo@redhat.com>, "clm@fb.com" <clm@fb.com>,
"jbacik@fb.com" <jbacik@fb.com>,
"dsterba@suse.com" <dsterba@suse.com>
Subject: Re: [PATCH 0/5] v2: block subsystem refcounter conversions
Date: Fri, 21 Apr 2017 08:03:13 -0600 [thread overview]
Message-ID: <31311853-3554-cefe-1210-2ffae1a20058@kernel.dk> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B41C8E21B@IRSMSX102.ger.corp.intel.com>
On 04/21/2017 04:55 AM, Reshetova, Elena wrote:
>>>> Please don't send any more conversions until those have been resolved.
>>
>> Like I suggested months ago, how about doing an efficient implementation of
>> refcount_t which doesn't use the bloated cmpxchg loop? Then there would be
>> no
>> need for endless performance arguments. In fact, in PaX there are already
>> example implementations for several architectures. It's unfortunate that
>> they're still being ignored for some reason.
>
> Providing efficient arch. specific implementation for refcount_t is
> likely the next step to make performance-sensitive places happy.
> However, in order to do it, we will need to measure for each subsystem
> a) current atomic_t usage - base measurement
> b) pure refcount_t usage impact
> c) arch. specific refcount_t impact
> Otherwise I have a chicken and egg problem here: people want better
> performance and want to see arch. specific code for this, but in order
> to convince maintainer in need of arch. specific code, I need to show
> that we do have indeed a performance issue.
Sorry, but that's a big load of...
You have it so easy - the code is completely standalone, building a
small test framework around it and measuring performance in _user space_
is trivial. Don't go around benchmarking conversions in specific
subsystems. Generate numbers showing how refcount_t compares to atomic_t
for various (valid) use cases.
Once you have that, convincing people to adopt it would be so much
easier. So stop talking about excuses, and start producing some numbers.
If you can't do that, my level of interest in converting anything in
block is zero.
--
Jens Axboe
next prev parent reply other threads:[~2017-04-21 14:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 11:27 [PATCH 0/5] v2: block subsystem refcounter conversions Elena Reshetova
2017-04-20 11:27 ` [PATCH 1/5] block: convert bio.__bi_cnt from atomic_t to refcount_t Elena Reshetova
2017-04-20 11:27 ` [PATCH 2/5] block: convert blk_queue_tag.refcnt " Elena Reshetova
2017-04-20 11:27 ` [PATCH 3/5] block: convert blkcg_gq.refcnt " Elena Reshetova
2017-04-20 11:27 ` [PATCH 4/5] block: convert io_context.active_ref " Elena Reshetova
2017-04-20 11:27 ` [PATCH 5/5] block: convert bsg_device.ref_count " Elena Reshetova
2017-04-20 13:56 ` [PATCH 0/5] v2: block subsystem refcounter conversions Christoph Hellwig
2017-04-20 16:10 ` Reshetova, Elena
2017-04-20 18:33 ` Eric Biggers
2017-04-21 10:55 ` Reshetova, Elena
2017-04-21 14:03 ` Jens Axboe [this message]
2017-04-21 15:22 ` Peter Zijlstra
2017-04-21 16:29 ` Jens Axboe
2017-04-21 17:11 ` Kees Cook
2017-04-21 19:55 ` Eric Biggers
2017-04-21 20:22 ` Kees Cook
2017-04-21 21:27 ` James Bottomley
2017-04-21 21:30 ` Kees Cook
2017-04-21 22:01 ` James Bottomley
2017-04-21 10:56 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31311853-3554-cefe-1210-2ffae1a20058@kernel.dk \
--to=axboe@kernel.dk \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ebiggers3@gmail.com \
--cc=elena.reshetova@intel.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=james.bottomley@hansenpartnership.com \
--cc=jbacik@fb.com \
--cc=keescook@chromium.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox