Re: statfs() / statvfs() syscall ballsup...

[Helge Hafting <helgehaf@aitel.hist.no>]

On Wed, Oct 15, 2003 at 11:03:23AM -0400, Greg Stark wrote:
> Ingo Oeser <ioe-lkml@rameria.de> writes:
> 
> > On Monday 13 October 2003 10:45, Helge Hafting wrote:
> > 
> > > This is easier than trying to tell the kernel that the job is
> > > less important, that goes wrong wether the job runs too much
> > > or too little.  Let that job  sleep a little when its services
> > > aren't needed, or when you need the disk bandwith elsewhere.
> 
> Actually I think that's exactly backwards. The problem is that if the
> user-space tries to throttle the process it doesn't know how much or when.
> The kernel knows exactly when there are other higher priority writes, it can
> schedule just enough writes from vacuum to not interfere.
> 
Isn't those higher-priority writes issued from userspace?
I am of course assuming that source for _everything_ is available.
So the process with the high-priority write can tell vacuum to
take a nap until its transaction completes.

> So if vacuum slept a bit, say every 64k of data vacuumed. It could end up
> sleeping when the disks are actually idle. Or it could be not sleeping enough
> and still be interfering with transactions.
> 
It can run at full speed normally, take voluntary pauses if it ever
detects a "nothing to do now" condition. And it can be paused
(forcibly or through cooperation) when there are important transactions
to sync. 

> Though actually this avenue has some promise. It would not be nearly as ideal
> as a kernel based solution that could take advantage of the idle times between
> transactions, but it would still work somewhat as a work-around.
> 
Don't that other process know when it is about to submit important transactions?

> > The questions are: How IO-intensive vacuum? How fast can a throttling
> > free disk bandwidth (and memory)?
> 

Helge Hafting