On Tue, Jul 16, 2002 at 12:41:38PM +0300, Nadav Har'El wrote: > On Tue, Jul 16, 2002, Muli Ben-Yehuda wrote about "Re: device files implementing >mmap": > > This is one that I'll have to benchmark (small read + mmap vs. large > > read), but it still doesn't solve the synchronization issue. How does > > You *will* need to use a system call that blocks until data is available > (after all, system calls are the interface between the kernel and user > space...), so a "small read" will do just like any other system call... > At least in this case you don't need to do two system calls.
Or, I will use an asynch. notification method - a signal, in other words. But the blocking syscall scenario is easier to implement. > > the double buffer technique solve it? > > The double buffer technique is used when the kernel passes data to the > user in an mmap, but then wants to write new data and doesn't know if the > user has read yet the last data; So two buffers are kept: the kernel writes > to one, the user reads from the other, and the roles of the two buffers are > switched on each read (or whatever it is called) system call. I was thinking > of the /dev/epoll driver > (http://www.xmailserver.org/linux-patches/nio-improve.html) as an example > of this, but it's probably not very relevant to your situation (which I > don't think I still understand completely...) Explanation: syscalltrack has a device file, /dev/sct_log. Whenever an event that needs to be logged occurs (for example, you had a rule matching all invocation of the 'open' syscall on the file '/etc/passwd/'), the logging mechanism adds a log record to the device file ring buffer. This cyclic ring buffer is 32kb in size (size will be configurable in run time as soon as I commit the patch to do so) and supports either 'drop old' or 'drop new' on overflow. Right now, user space reads from the buffer using the read system call. The kernel does all book keeping, maintaining a read head and a write head for the cyclic ring buffer, and all user space clients have to do is rc = read(fd, buf, count); in other words, you can read the device file with cat(1) just fine. The logging device file code is at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/syscalltrack/syscalltrack/sct_rules_module/log_dev.c The cyclic ring buffer code is at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/syscalltrack/syscalltrack/sct_rules/membuf.c In the interest of performance (and experimenting and learning new things), I want to implement an mmap interface to the buffer. Since user space accesses the buffer independently of any system call, there's no way for the kernel to synchronize accesses. The double buffer technique would indeed solve this problem. > > This is turning into a mystery. Pretty much every sound/video driver > > out there does this 'mmap into a ring buffer and let user space read > > it', they can't all be racy! More digging into the code is required. > > I didn't read sound-driver any code, so maybe I'm not the right person to > answer this... But I'm not sure how much race protection a sound driver > would need. Consider my read() interface (for example), a 100K circular > buffer, and an application being notified (as a result of that read()) that > it can now read 10K of data starting in postion 12345 in the buffer. > The worst thing that could happen (synchronization-wise) is that the > application waits too long before it finally uses that data, and before it > does the driver already circles around the entire buffer, overwriting the > same location with new data. This "problem" will manifest itself as "skips" > in sound recording when the computer is very busy - I don't think this is > such a serious problem... It's not if you use the double buffer, since you always get old but correct data. If you use a single buffer, you might get garbage (you're reading a chunk, and as you read it, it gets overwritten by the kernel). Sounds like I'll drop tbe mmap idea for now unless benchmarks show that read() is too slow due to the copying. It makes the client interface more complicated for no good reason, and it doubles the memory consumption required. Thanks for you comments! -- http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/
msg20517/pgp00000.pgp
Description: PGP signature
