Date: Wed, 06 Jun 2007 12:25:52 +1000 From: Lawrence Stewart <lstewart@room52.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= <des@des.no> Subject: Re: Writing a plain text file to disk from kernel space Message-ID: <46661B30.10404@room52.net> In-Reply-To: <200706051539.22662.jhb@freebsd.org> References: <4649349D.4060101@room52.net> <86odkcugev.fsf@dwp.des.no> <46565781.2030407@room52.net> <200706051539.22662.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi John, Thanks for the reply and additional information on locks. The solution I've just completed working on is designed exactly as you describe. We're about to begin testing and evaluating the module, and we'll be releasing the code and 2 technical reports related to it within the coming weeks with any luck. The first report describes the module and its performance characteristics... only interesting to people doing TCP related research with FreeBSD. The other report is a sort of "intro to FreeBSD kernel hacking" paper, which is a brain dump of all the useful lessons we've learnt throughout the process. This report is mostly for our benefit so we remember the lessons we learnt for next time, but we're hoping it will also be something useful for the community to point noob kernel hackers at for some introductory information. I'll be posting to this list as soon as the code and reports are available, as it has been indicated by people following this thread that having some sort of tutorial/reference information would be useful. Cheers, Lawrence John Baldwin wrote: > Use a task to defer the kio_write() to a taskqueue. You have to malloc state > (using M_NOWAIT, which can fail) to do this properly. If you are doing this > for every packet, you are probably better off using malloc() to throw items > into a queue and having a global task that drains the queue on each execution > doing kio_write()'s for each object. > > Regarding sleepable vs. non-sleepable locks. Getting preempted by an > interrupt is not considered "sleeping". Sleeping means voluntarily yielding > the CPU to wait for an event such as via msleep() or a condition variable. > Note that interrupt handlers can acquire non-sleepable locks. If you sleep > while holding a non-sleepable lock, you may have an interrupt handler that > can't run while it waits for some async event (like disk I/O) to complete. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46661B30.10404>