linux-kernel - Re: RSDL-mm 0.28

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Mar 2007 22:01:32 -0600
From:	Matt Mackall <mpm@...enic.com>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, ck@....kolivas.org
Subject: Re: RSDL-mm 0.28

On Sun, Mar 11, 2007 at 01:28:22PM +1100, Con Kolivas wrote:
> >make -j 5 ccache
> > beryl    ok          good           awful
> > galeon   good        good           bad
> > mp3      good        good           bad
> > terminal good        good           bad/ok
> > mouse    good        good           bad/ok
...
> >RSDL makes most of the noyield hit back in normal make and then some
> >with ccache. Impressive. But ccache is still destroying interactivity
> >somehow. The ccache effect is fairly visible even with non-parallel
> >'make'.
> 
> Ok I don't think there's any actual accounting problem here per se
> (although I did just recently post a bugfix for rsdl however I think
> that's unrelated). What I think is going on in the ccache testcase is
> that all the work is being offloaded to kernel threads reading/writing
> to/from the filesystem and the make is not getting any actual cpu
> time.

I don't see significant system time while this is happening.

> This is "worked around" in mainline thanks to the testing for
> sleeping on uninterruptible sleep in the interactivity estimator. What
> I suspect is happening is kernel threads that are running nice -5 are
> doing all the work on make's behalf in the setting of ccache since it
> is mostly i/o bound. The reason for -nice values on kernel threads is
> questionable anyway. Can you try renicing your kernel threads all to
> nice 0 and see what effect that has? Obviously this doesn't need a
> recompile, but is simple enough to implement in kthread code as a new
> default.

Sorry, little to no benefit.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/