Looks good to me. You may want to explain in the documentation why user memory is better than kernel memory. Not everyone knows about this. Again we are appreciative but will be slow and careful to test; I haven't compiled my own kernel since Linux 1.1.54 on Slackware.
-Jeff On Thu, Aug 20, 2009 at 6:48 AM, <sf...@users.sourceforge.net> wrote: > > Hi Jeff, > >> With this patch, most of your problem will be solved. But it won't fix >> all cases, since aufs VDIR still consumes much memory. In the real >> memory starvation or fragmented situation, the message will appear again. >> I will restart developing VDIR implementation in userspace which stops >> aufs to consume much memory. It may take a few weeks. Until then, please >> try this patch against ubuntu hardy kernel. > > I hope the patch is working fine on your side. > And here is my plan to develop VDIR in userspace and I am testing now. > Do you think it will be useful for you? > > ---------------------------------------------------------------------- > .SH VDIR/readdir(3) in user\-space (RDU) > If you have a directory which has millions of files, aufs VDIR consumes > much memory. You may meet "out of memory" message due to > the memory fragmentation or real starvation. In this case, RDU > (readdir(3) in user\-space) may help you. > > If you enable CONFIG_AUFS_RDU at compiling aufs, and install libau.so in > aufs2-util GIT tree (by "make install_ulib"), then you can use RDU. > Just simply set the environment variable "LD_PRELOAD=libau.so" > and run your application. The dynamic link library libau.so implements > readdir(3), and all readdir(3) calls in your application will be handled > by libau.so. It doesn't issue readdir(3) to aufs. Instead, it gets > all filenames under the dir by another method and merges them by > itself. In other words, > libau.so moves the memory consumption in kernel\-space to user\-space. > > While it is good to stop consuming much memory in kernel\-space, > sometimes the speed performance may be damaged a little as a side > effect. > It is just a little, I hope. > > If your directory is not so huge and you don't meet the out of memory > situation, probably you don't need this library. > > .SS Note > Since this is a dynamically linked library, it in unavailable if your > application is statically linked. And ld.so(8) ignores LD_PRELOAD when > the application is setuid/setgid\-ed unless the library is not > setuid/setgid\-ed. It is a generic rule of > dynamically linked library. > ---------------------------------------------------------------------- > > J. R. Okajima > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
