Messages in this thread | | | Date | Wed, 15 Oct 2003 20:37:10 +0200 | Subject | Re: statfs() / statvfs() syscall ballsup... | From | Helge Hafting <> |
| |
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 - 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/
| |