[ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

[ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

Post by Andrew Morto » Sun, 23 Feb 2003 09:10:06




> ..

> > The correct way to design such an application is to use an RT thread to
> > perform the display/audio device I/O and a non-RT thread to perform the disk
> > I/O.  The disk IO thread keeps the shared 8 megabyte buffer full.  The RT
> > thread mlocks that buffer.

> This requires making xmms suid root. Do you really want to do that?

> Also who takes care about all the security holes that would cause?

> If you require applications doing such things to work around VM/scheduler
> breakage

It is utterly unreasonable to characterise this as "breakage".

No, we do not really need to implement RLIM_MEMLOCK for such applications.
They can leave their memory unlocked for any reasonable loads.

Yes, we _do_ need to give these applications at least elevated scheduling
priority, if not policy, so they get the CPU in a reasonable period of
time.

Quote:> But both is quite a bit of work, especially the later and may impact
> other loads. Fixing the IO scheduler for them is probably easier.

You have not defined "fix".  An IO scheduler which attempts to serve every
request within ten milliseconds is an impossibility.  Attempting to
achieve it will result in something which seeks all over the place.

The best solution is to implement five or ten seconds worth of buffering
in the application and for the kernel to implement a high throughput general
purpose I/O scheduler which does not suffer from starvation.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

Post by Alan Co » Mon, 24 Feb 2003 03:11:40



> No, we do not really need to implement RLIM_MEMLOCK for such applications.
> They can leave their memory unlocked for any reasonable loads.

> Yes, we _do_ need to give these applications at least elevated scheduling
> priority, if not policy, so they get the CPU in a reasonable period of
> time.

It isnt about CPU, its about disk. If the app gets a code page swapped
out then unless we have disk as well as cpu priority, or we do memlock
stuff you are screwed. I guess the obvious answer with 2.5 is to
simply abuse the futex bugs and lock down futex pages with code in ;)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

Post by Ingo Oese » Mon, 24 Feb 2003 03:11:39



> You have not defined "fix".  An IO scheduler which attempts to serve every
> request within ten milliseconds is an impossibility.  Attempting to
> achieve it will result in something which seeks all over the place.

> The best solution is to implement five or ten seconds worth of buffering
> in the application and for the kernel to implement a high throughput general
> purpose I/O scheduler which does not suffer from starvation.

What about implementing io-requests, which can time out? So if it will
not be serviced in time or we know, that it will not be serviced
in time, we can skip that.

This can easily be stuffed into the aio-api by cancelling
requests, which are older than a specified time. Just attach a
jiffie to each request and make a new syscall like io_cancel but
with a starting time attached. Or even make it a property of the
aio list we are currently handling and use a kernel timer.

That way we could help streaming applications and the kernel
itself (by reducing its io-requests) at the same time.

Combined with you buffering suggestion, this will help cases,
where the system is under high load and cannot satisfy these
applications anyway.

What do you think?

Regards

Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

Post by Andrea Arcangel » Mon, 24 Feb 2003 17:40:14



> request within ten milliseconds is an impossibility.  Attempting to
> achieve it will result in something which seeks all over the place.

This is called SFQ, or CFQ with 0 dispatch queue level and it works
fine (given a fixed amount of tasks doing I/O). You still don't
understand you don't care about throughput and seeks if you only need to
read 1 block with the max fairness and you don't mind to read another
block within 1 second. seeking is the last problem here, waiting more
than 1 second is the only problem here.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

Post by Andrea Arcangel » Mon, 24 Feb 2003 17:50:10




> > You have not defined "fix".  An IO scheduler which attempts to serve every
> > request within ten milliseconds is an impossibility.  Attempting to
> > achieve it will result in something which seeks all over the place.

> > The best solution is to implement five or ten seconds worth of buffering
> > in the application and for the kernel to implement a high throughput general
> > purpose I/O scheduler which does not suffer from starvation.

> What about implementing io-requests, which can time out? So if it will
> not be serviced in time or we know, that it will not be serviced
> in time, we can skip that.

> This can easily be stuffed into the aio-api by cancelling
> requests, which are older than a specified time. Just attach a
> jiffie to each request and make a new syscall like io_cancel but
> with a starting time attached. Or even make it a property of the
> aio list we are currently handling and use a kernel timer.

> That way we could help streaming applications and the kernel
> itself (by reducing its io-requests) at the same time.

> Combined with you buffering suggestion, this will help cases,
> where the system is under high load and cannot satisfy these
> applications anyway.

> What do you think?

that works only if the congestion cames from multimedia apps that are
willing to cancel the timed out (now worthless) I/O, that is never the
case normally due the low I/O load they generate (usually it's apps not
going to cancel the I/O that congest the blkdev layer).

still, it's a good idea, you're basically asking to implement the cancel
aio api and I doubt anybody could disagree with that ;).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

Post by Ingo Oese » Mon, 24 Feb 2003 21:40:11




> > What about implementing io-requests, which can time out? So if it will
> > not be serviced in time or we know, that it will not be serviced
> > in time, we can skip that.

> that works only if the congestion cames from multimedia apps that are
> willing to cancel the timed out (now worthless) I/O, that is never the
> case normally due the low I/O load they generate (usually it's apps not
> going to cancel the I/O that congest the blkdev layer).

I would put it to loads, where it doesn't matter that all streams
will be serviced all the time and where it does matter more, that
we stay responsive and show the latest frames available.

Quote:> still, it's a good idea, you're basically asking to implement the cancel
> aio api and I doubt anybody could disagree with that ;).

I'm aware of these, but if we are so heavily busy, that the
applications looses IO frames already, then calling into an
application (which might be swapped out) to traverse its
AIO overhead the cancel makes no sense any more.

I want a deadline attached to them and have them automatically
cancelled after this deadline. (that's why I quoted the relevant
part of my e-mail again).

I can see many uses besides multi media applications. Also http
or ftp server could do this, if they are busier as expected or if
a connection dropped.

Regards

Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

Post by Andrea Arcangel » Tue, 25 Feb 2003 01:40:07





> > > What about implementing io-requests, which can time out? So if it will
> > > not be serviced in time or we know, that it will not be serviced
> > > in time, we can skip that.

> > that works only if the congestion cames from multimedia apps that are
> > willing to cancel the timed out (now worthless) I/O, that is never the
> > case normally due the low I/O load they generate (usually it's apps not
> > going to cancel the I/O that congest the blkdev layer).

> I would put it to loads, where it doesn't matter that all streams
> will be serviced all the time and where it does matter more, that
> we stay responsive and show the latest frames available.

> > still, it's a good idea, you're basically asking to implement the cancel
> > aio api and I doubt anybody could disagree with that ;).

> I'm aware of these, but if we are so heavily busy, that the
> applications looses IO frames already, then calling into an

Note that we're dealing with a disk heavily busy since they're timing
out, but we're not necessairly cpu-busy at all. The cancellation is a
completely disk-less operation, it runs at cpu core speed. A simple
getevents with timeout + io_cancel will do the trick just fine. Sure,
this way the cancellation will have to run a bit of userspace code too,
but it shouldn't make that much difference in practice (at least unless
there's an heavy cpu or swap overload too that introduce an huge time
gap between the getevents timeout and the io_cancel to enter kernel).
Your API makes sense too, but it's just a different API and I'm not sure
if it worth to implement it at the light of the above considerations,
given we just have the io_cancel syscall. Also note that the
cancellation API makes sense even if we don't work in the disk-queue
layer, infact unless you've a 4G worthless I/O queue like in Andrew's
example, probably it won't make an huge difference to cancel the I/O in
the queue too, even if of course it would make perfect sense to do that
too.  it is especially difficult to cancel the I/O in the disk queue at
the moment because we can't make sure what is our request and what is
somebody else request. Same goes for your cancellation API, it would be
difficult to cancel it. Everything in the queue is asynchronous and not
everybody will wait on its stuff immediatly.

Quote:> application (which might be swapped out) to traverse its
> AIO overhead the cancel makes no sense any more.

again, we're not necessairly swapped out, the aio api should take care
of the I/O congestions, not necessairly of the VM and cpu congestions.
And for the I/O congestions it looks sane to me even if it will have to
pass through userspace, but passing through userspace may be an
advantage some time (so you can choose how much to cancel or whatever).

Quote:> I want a deadline attached to them and have them automatically
> cancelled after this deadline. (that's why I quoted the relevant
> part of my e-mail again).

Sure I understood your point.

Quote:> I can see many uses besides multi media applications. Also http
> or ftp server could do this, if they are busier as expected or if
> a connection dropped.

Not sure how much you can save, disconnects shouldn't be so frequent and
filling the cache anyways may make sense specially for http, and the
timeouts are quite long, by the time the network timeout trigger likely
the I/O just completed since a long time, and it wouldn't be easy to
synchronize the network timeout with the request submit-time-timeout. I
believe cancellation matters for interactive applications, and http and
ftp aren't interactive, I mean, there's not a throughput requirement for
http/ftp, nor a frame rate to keep up with, if flash or java takes
longer to load because your network is slower, you'll just wait longer etc..

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. iosched: impact of streaming read on read-many-files

Here we look at what affect a large streaming read has upon an operation
which reads many small files from the same disk.

A single streaming read was set up with:

        while true
        do
                cat 512M-file > /dev/null
        done

and we measure how long it takes to read all the files from a 2.4.19 kernel
tree off the same disk with

        time (find kernel-tree -type f | xargs cat > /dev/null)

2.4.21-pre4:    31 minutes 30 seconds

2.5.61+hacks:   3 minutes 39 seconds

2.5.61+CFQ:     5 minutes 7 seconds (*)

2.5.61+AS:      17 seconds

* CFQ performed very strangely here.  Tremendous amount of seeking and a
  big drop in aggregate bandwidth.  See the vmstat 1 output from when the
  kernel tree read started up:

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  1   1240 125260   1176 109488    0    0 40744     0 1672   725  0  3 49 47
 0  1   1240  85892   1220 148788    0    0 39344     0 1651   693  0  3 49 48
 0  1   1240  45124   1260 189492    0    0 40744     0 1663   683  0  3 49 47
 1  1   1240   4544   1300 230068    0    0 40616     0 1661   837  0  4 49 47
 0  2   1348   3468    944 231696    0  108 40488   148 1671   800  0  4  4 91
 0  2   1348   2180    936 232920    0    0 40612    64 1668   789  0  4  0 96
 0  3   1348   4220    996 230648    0    0 11348     0 1256   352  0  2  0 98
 0  3   1348   4052   1064 230472    0    0  9012     0 1207   305  0  1  0 98
 0  4   1348   3596   1148 230580    0    0  6756     0 1171   247  0  1  0 99
 0  4   1348   4044   1148 229888    0    0  6344     0 1165   237  0  1  0 99
 1  3   1348   3708   1160 230212    0    0  7800     0 1187   255  0  1 21 78

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. rz/sz problem

3. iosched: impact of streaming write on read-many-files

4. which distro and version....

5. iosched: impact of streaming write on streaming read

6. Redhat 6.0 & ftp / nfs

7. iosched: effect of streaming read on streaming write

8. Newbie wants to connect 2 computers.

9. iosched: parallel streaming reads

10. iosched: effect of streaming read on interactivity

11. iosched: concurrent reads of many small files

12. LILO answers HERE read read read

13. Reading a de-limited files across Carriage Returns