Date: Wed, 30 Jul 2003 12:34:27 -0700
From: Andrew Morton <akpm@osdl.org>
To: aradorlinux@yahoo.es
Cc: kernel@kolivas.org, miller@techsource.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] O10int for interactivity
Message-Id: <20030730123427.50d128ea.akpm@osdl.org>
In-Reply-To: <20030730212832.22e065ad.aradorlinux@yahoo.es>
References: <200307280112.16043.kernel@kolivas.org>
	<200307300035.01354.kernel@kolivas.org>
	<20030730031616.3ed14362.diegocg@teleline.es>
	<200307301136.06396.kernel@kolivas.org>
	<20030730212832.22e065ad.aradorlinux@yahoo.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1882
Lines: 41

aradorlinux@yahoo.es wrote:
>
> [changing email address; several hosts block mail from *@teleline/terra.es;
> which is good if they're fighting against spam]
> El Wed, 30 Jul 2003 11:36:06 +1000 Con Kolivas <kernel@kolivas.org> escribi?:
> 
> > The logic is in the difference between the dynamic and the static priority to 
> > determine if a task is interactive. 
> > current->static_prio - current->prio
> > will give you a number of -5 to +5, with +5 being a good bonus and vice versa.
> > however you need to ensure that the value you are fiddling with in the i/o 
> > scheduler is actually due to the current process[1]
> 
> I think current really is the process submitting the request; at least in the
> same function we've this:
> 
>         if (rq_data_dir(arq->request) == READ
>                         || current->flags&PF_SYNCWRITE)
> 
> Which would be wrong if current isn't the process submitting the request.

`current' is correct for reads and synchronous writes.  It is usually wrong
for normal pagecache writeback.

If we're going to do this sort of thing, the IO priority and any associated
state should be placeed into struct io_context, which is the structure with
which the IO scheduler tracks per-process stuff.

The io_context is constructed just once across teh lifetime of a process,
so we'd need to update it occasionally to pick up dynamic priority shifts,
changes in niceness, etc.  Probably do that inside a read.

I have a vague feeling that co-opting the scheduling priority information
for use as IO priority will end up being a mistake.  It may be best to
treat these things separately from the outset.

-
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/