https://bugs.kde.org/show_bug.cgi?id=356357
k...@web.de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |k...@web.de
--- Comment #5 from k...@web.de ---
> Vishesh, Baloo is a worthy attempt at an indexing system, and I commend your
> work. It uses a quality database backend in the form of LMDB. But any which
> way you and I might spin it, Baloo has a serious problem with I/O: it simply
> causes too much of it, too frequently. Numerous users have complained about
> this, and several currently open and closed bugs are traceable directly to
> this behaviour. Several users' impressions of Baloo, and KDE writ large, are
> tainted by Baloo's abusive disk activity.
https://linux.die.net/man/1/ionice
[...]
Idle
A program running with idle io priority will only get disk time when no
other program has asked for disk io for a defined grace period. The impact of
idle io processes on normal system activity should be zero. This scheduling
class does not take a priority argument. Presently, this scheduling class is
permitted for an ordinary user (since kernel 2.6.25).
Best effort
[...]
Baloo's priority is set to Idle, which means it should not cause "abusive" disk
activity.
Unless your IO scheduler does not support ionice. Could this be your problem?
https://blogs.kde.org/2014/10/15/ubuntus-linux-scheduler-or-why-baloo-might-be-slowing-your-system-1404
> Here's a relatively simple proposal: The indexer operates on a configurable
> *duty cycle* D of 1%-50% and a time period T of 1s-3600s. For (1-D)*T seconds
> per period, Baloo sleeps. For D*T seconds per period, Baloo *exclusively*
> performs data/metadata reads from the filesystem, keeping an eye on
> wall-clock time. Once D*T seconds of work have elapsed, make a *single
> transaction* containing all of the stuff that the indexer read in the
> previous duty cycle. Then go back to sleep again. In this way, exactly one
> mdb_txn_commit() and fdatasync()/msync() occurs per time period, they are
> likely to have accumulated far more than 40 files worth of information, and
> 50-99% of I/O bandwidth is available for other uses, such as satisfying the
> desktop UI's needs.
You are suggesting rate limiting the IO. Rate limiting is inferior to
scheduling (which is already being done) because:
1. The rate limit is wasting (1-D) of the available bandwidth in idle
situations. (When baloo is the only application using IO.)
2. If Bmin < 1 is needed to satisfy the user requirements, (1-D) might still be
smaller than Bmin. Scheduling with Idle priority will leave 1 instead of of
(1-D) to the user, which is enough in any case. Also, now we don't need to find
Bmin anymore.
Anyway, minimizing the caused IO is still useful.
--
You are receiving this mail because:
You are watching all bug changes.
