>       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'll see how we get along when he answers my mail. Maybe we can as well
discuss some other stuff.

> > I just tried the "documented" solution:
> > write(1,buffer,width*height*2); fdatasync(1);
> Agh!  That is not what fdatasync(1) is for!  

What else would it be for ? It in deed does make sure that the file actually
gets written to disk, what lets me synchronize with the disk speed.

What would you suggest to use ? fsync seems worse.

The problem with both functions is, that their required runtime is of the
order of the total file size, not the change file size.

This causes my framerate to drop from full 25fps down to 4 fps after about
600 frames. ARGL.

> 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?

I don't care about avoiding it, I just care about making sure it doesn't
fill up a huge piece of memory that is then flushed in a big gulp later on,
giving me a bunch of consecutively missing frames.

> > 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!

It's just sick.

>       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.

It is. Search for rawio or raw-io and +Linux with Altavista. There you should
find a digest about a thread on exactly that topic.

It is full of sick proposed solutions: "Turn off fsync for the syslogd
files.", "Log to an external host.", "Syslogd is badly written anyway." ...

CU, Andy

-- 
= Andreas Beck                    |  Email :  <[EMAIL PROTECTED]> =

Reply via email to