To: Dimitri Sivanich <sivanich@sgi.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: Option to run cache reap in thread mode
References: <27JKg-4ht-11@gated-at.bofh.it>
From: Andi Kleen <ak@muc.de>
Date: Wed, 16 Jun 2004 18:22:28 +0200
In-Reply-To: <27JKg-4ht-11@gated-at.bofh.it> (Dimitri Sivanich's message of
 "Wed, 16 Jun 2004 16:40:16 +0200")
Message-ID: <m3r7sfmq0r.fsf@averell.firstfloor.org>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1110
Lines: 25

Dimitri Sivanich <sivanich@sgi.com> writes:

> I would like to know what others think about running cache_reap() as a low
> priority realtime kthread, at least on certain cpus that would be configured
> that way (probably configured at boottime initially).  I've been doing some
> testing running it this way on CPU's whose activity is mostly restricted to
> realtime work (requiring rapid response times).
>
> Here's my first cut at an initial patch for this (there will be other changes
> later to set the configuration and to optimize locking in cache_reap()).

I would run it in the standard work queue threads. We already have 
too many kernel threads, no need to add more.

Also is there really a need for it to be real time? 
Note that we don't make any attempt at all in the linux kernel to handle
lock priority inversion, so this isn't an argument.

-Andi

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