On Mon, 4 Oct 1999, Andreas Beck wrote:
> > 2.3.x kernel have Stephen Tweedie's 'rawio' patch, which IIRC is
> > designed specifically to deal with this problem.
>
> I just looked for it ... If you hadn't given me the right keyword, I'd never
> have found it ... though it is not specifically what I need I don't really
> want to mount a whole disk as rawio ...
Oh well.
> But I'll contact Stephen about it. Looking at the Linux-Kernel reviews,
> we'll probably get along well :-).
I like to read what he writes too. He has a very good grasp of
low-level issues and optimizations. I wonder what he thinks of ping-pong
buffers?
> I just tried the "documented" solution:
> write(1,buffer,width*height*2); fdatasync(1);
Agh! That is not what fdatasync(1) is for! The manpage says that
it syncs the file data but the metadata (date modified, etc). That's it!
How can that work to avoid the cache?
> Don't ask what happens if you do it. You wouldn't believe me anyway.
Well, I had to see it for myself, but I just don't believe it for
sure. There _has_ to be a better solution than to block the whole kernel
like that! That is ridiculous! Is that even SMP-safe (does it do a
spinlock)?? And it doesn't even work right for what the manpage says it is
supposed to do (sync the file without updating the timestamp), although
the fact that fdatasync() behaves the same as fsync() is at least well
documented. Gimme a break!
I wonder if this is why I start to lose chunks out of my syslogs
when I really crank up the number of printk()s in a kgicon driver. All
these years I have seen this happen and wondered what was behind it.
This might explain it. We should investigate and have someone bring it up
on linux-kernel if there is a real problem here, so it can get fixed for
2.3/2.4.
> I think it is a major wonder, that stuff like syslogd works at all for large
> sites.
This is where xBSDs shine over Linux. They may not be ported to
as many architectures or have as many drivers or crazy SMP support, but
their internals are much cleaner and the whole system is more tuned and
balanced. Much of the internals of the Linux kernel, in contrast, is a
crazy-quilt patchwork of performance hacks that end up binding your system
as it tries to grow and scale. Little QuickHacks build up in odd corners
and come out to bite your ass when you try to seriously exercise the odd
corner's functionality because it does what you want cleanly. I trip over
them all the time when you do kgicon work.
Still, Linux is a success largely because Linus allows more kudzu
in, which causes the whole thing to look ugly but grow like crazy. I
guess I can't argue with results, though - the code does eventually get
fixed up, and the extra growth may be worth it. It sure makes Linux
kernel development a lot more of a hassle at times than it needs to be,
though. In spite of what most kernel developers always say about his
tough standards leading to high quality, a lot of new kernel code goes
through a nasty sorta-broken period before it stabilizes out. Sometimes
it takes a while (years for ISDN and decent SMP), and sometimes it never
happens (NFS, the console system).
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
