On 10/18/2017 07:19 AM, Tejun Heo wrote:

quoted

We tried to understand the reason for this high overhead, and, in
particular, to find out whether whether there was some issue that we
could address on our own.  But the causes seem somehow substantial:
one of the most time-consuming operations needed by some blkg_*stats_*
functions is, e.g., find_next_bit, for which we don't see any trivial
replacement.

Can you point to the specific ones?  I can't find find_next_bit usages
in generic blkg code.

Yeah, in general a report like this is pretty much useless without
any sort of call traces or perf output. The best way to get help
is to post exactly what to run to reproduce the performance issue,
and profile output that shows/highlights the issues.

-- 
Jens Axboe