Actually the unbounded delays is not an issue as the lookups are usually happening as deferred work, and most of my code is in kernel space so I'm not sure if pushing off the hashtable lookup code to userspace is a good idea.. Thanks for pointing out that mmap wouldn't work in kernel space. But out of curiosity, does this have to do with the fact thatmm is set to NULL for a kernel thread task_struct? Why would page faults result in an OOPs because if I vmalloc something in the kernel, isn't it already mapped? Thanks, -Joel On Fri, Jan 8, 2010 at 11:12 PM, Bryan Donlan <bdonlan@xxxxxxxxx> wrote: > On Wed, Jan 6, 2010 at 4:20 AM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote: >> There is a certain hashtable that I am currently implementing in the >> kernel using file handling for sake of persistence. It is actually a >> file-based binary tree (nodes are referred to by file offsets instead >> of memory addresses). The problem is that the tree can get unbalanced >> quite quickly and after a while, hashtable lookups slow down. >> >> Is there a way I can use the kernel rb-tree mechanism and yet keep the >> data persistent (that is every time I update the tree, the update is >> also committed to disk and can be reloaded in the future). >> I am thinking of using vmalloc to allocate a contiguous chunk of >> virtual memory, and then use mmap to make it persistent, but again >> this has problems like I can't have the slab allocator use this >> vmalloc'ed memory. Any ideas? > > You can't mmap directly from the kernel at all; page faults will > result in an OOPS. If I were you, I'd consider if this hashtable > really needs to be in the kernel, or if it can be in userspace using a > more typical SQL server or something. After all, you're already going > to need to deal with memory pressure and unbounded delays if you're > considering doing IO on lookups, so pushing it off to userspace ought > not to be a huge problem. > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
