Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jul 2000 11:26:10 -0700
From:      Lars Eggert <larse@ISI.EDU>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Alan Cox <alc@cs.rice.edu>, hackers@FreeBSD.ORG, cort@cs.nmt.edu
Subject:   Re: clearing pages in the idle loop
Message-ID:  <397C8A42.BF52CC4D@isi.edu>
References:  <20000719234124.H14543@cs.rice.edu> <39788E48.60F8A59F@isi.edu> <200007211906.MAA19989@earth.backplane.com> <3978A802.E05CC45@isi.edu> <200007221739.KAA31376@earth.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote:
> 
> :>     Since the only effect of a cache miss is less efficient use of
> :>     the cpu, and since the page zeroing only occurs when the cpu is idle,
> :>     I would not expect to see much improvement from attempts to refine
> :>     the page-zeroing operation (beyond the simple hysteresis that FreeBSD
> :>     uses now and perhaps being able to bypass the cache).
> :
> :The reason why I'm interested in Cort's results is that I'd like to extend
> :processing in the idle loop to other things (see my other mail). Cort
> :measured a performance decrease of foreground processing, due to polluted
> :caches after idle-time processing. We're discussing if disabling caches
> :during the idle loop may prevent that.
> 
>     I think what you are observing may not be cache-related at all, but may
>     simply be the fact that zeroing a page takes a minimum amount of time
>     during which another task will not be scheduled, verses that other task
>     being scheduled instantly if all the idle loop were doing was checking
>     for new tasks to run.

The way Cort implemented it in Linux was so that there's a check for new
processes in the loop that clears a page. This is of course slowing it, but
since it's idle time processing, reduction of latency to start a new
process (and being transparent to foreground processing in general) is much
more important than optimized execution. 

This is also why turning off L1 and L2 caches may be interesting - if one
process blocks, you do some idle time processing and it unblocks, the L1
and L2 cache may be polluted by the idle time processing, slowing things
down for the foreground process.
 
>     Another alternative is to have an idle process rather then try to do
>     things in the idle loop.  This has the advantage of being instantly
>     interruptable if a 'real' process becomes runnable, but the disadvantage
>     of having to do a context switch (albeit a relatively cheap one).

That would probably be the cleanest solution. Maybe the idprio mechanism
could be extended to cover this.
-- 
Lars Eggert <larse@isi.edu>                 Information Sciences Institute
http://www.isi.edu/larse/                University of Southern California


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?397C8A42.BF52CC4D>