Reduce log I/O latency To ensure that log I/O is issued as the highest priority I/O, set the I/O priority of the log I/O to the highest possible. This will ensure that log I/O is not held up behind b
Won't that possible disturb other RT priority users that do not need log IO (e.g. working on preallocated files)? Seems a little dangerous. I suspect you want a "higher than bulk but lower than RT" p
In all the cases that I know of where ppl are using what could be considered real-time I/O (e.g. media environments where they do real-time ingest and playout from the same filesystem) the real-time
I've seen PVRs that would be upset by this. They put media on one filesystem and database/apps/swap/etc. on another, but have everything on a single spindle. Stalling a media filesystem read for a wr
Sounds like the PVR is badly designed to me. If a write can cause a read to miss a playback deadline, then you haven't built enough buffering into your playback application. Cheers, Dave. -- Dave Chi
FWIW from a "real time" database POV this seems to make sense to me... in fact, we probably rely on filesystem metadata way too much (historically it's just "worked".... although we do seem to get is
Normally it's not a problem. But your proposed change can push a working system into a non-working system by making non-critical I/O on an unrelated filesystem have higher priority than the thing tha
This has nothing to do with this patch - it's a problem with sharing a single resource in a RT system between two non-deterministic constructs. e.g. I can put two ext3 filesystems on the one spindle,
For that case you really would need priority inheritance: any metadata IO on behalf or blocking a process needs to use the process' block IO priority. David's change just fixes a limited set of case
How do you do that when the processes are blocking on semaphores, mutexes or rw-semaphores in the fileysystem three layers removed from the I/O in progress? e.g. a low priority process transaction is
Sure. And it's up to the RT system designer not to do something stupid like that. The problem is that your patch potentially promotes a non-RT I/O activity to an RT one without regard to the rest of
So this: http://marc.info/?l=linux-kernel&m=119247074517414&w=2 shouldn't be allowed, either? (rt kjournald for ext3) Ok. I'll point anyone that complains at you, Matt ;) See my reply to Andi. No, no
Actually, I might change it to use the highest non-rt priority, which would solve the latency issues in the normal cases and still leave the RT rope dangling for those that want to use it. Is that an
No, I think not. If a user wants to manually promote kjournald, that's fine. I did. And I'll admit it's pretty thorny and I certainly don't know enough about XFS internals to comment further. I was a
[...] I didn't say it was easy (or rather explicitely said it would be tricky). Probably it would be possible to fold it somehow into rt mutexes PI, but it's not easy and semaphores would need to be
The point is that it's not actually a thread-based problem - the priority can't be inherited via the traditional mutex-like manner. There is no connection between a thread and an I/o it has already i
It could be handled in theory similar to standard CPU priority inheritance -- \ keep track of IO priority of all threads you block and boost your IO priority always to that level. But it would be pro
Well I think what Dave is saying is that we can't find the related process. The submitter process may have even exited before the flush happens.. You'd instead have to keep track of (the max of) all