Date: Mon, 17 Dec 2007 15:41:39 -0500 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-hackers@FreeBSD.org Cc: Jeremy Chadwick <koitsu@FreeBSD.org>, Gerald Heinig <gheinig@marvell.com>, Sonja Milicic <tanarri@geri.cc.fer.hr> Subject: Re: Large array in KVM Message-ID: <200712171541.39959.jhb@freebsd.org> In-Reply-To: <20071207112351.GA6544@eos.sc1.parodius.com> References: <4D634BCFD1A2144ABECC75FF512D7A9001DF60BE@SKGExch01.marvell.com> <20071207112351.GA6544@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 07 December 2007 06:23:51 am Jeremy Chadwick wrote: > On Fri, Dec 07, 2007 at 10:43:00AM +0100, Gerald Heinig wrote: > > Hi Sonja, > > > > > Hi everyone. > > > > > > I'm working on a kernel module that needs to maintain a large > > structure > > > in memory. As this structure could grow too big to be stored in > > memory, > > > it would be good to offload parts of it to the disk. What would be the > > > best way to do this? Could using a memory-mapped file help? > > > > How about implementing your code as a system call, which is called from > > a process that maps a large file into memory, as you suggested above. > > I presume you'd have to handle the question of whether or not your pages > > are in memory yourself, ie. pretty much like any other system call. > > > > Interesting question. > > Somewhat related question: > > What purpose does SYSCALL_MODULE(9) serve? I attempted to use this last > month while writing a kernel module of my own, and was never able to get > it to work for (what understood to be) a couple different reasons: > > 1) There's a maximum # of syscalls permitted (see SYS_MAXSYSCALL in > include/sys/sycall.h), which means a dynamically-allocated syscall via > SYSCALL_MODULE(9) cannot be inserted into the syscalls list. > > 2) The example code in share/examples/kld/syscall/module/syscall.c > specifies the sysent offset as NO_SYSCALL (e.g. -1). You can't pick an > arbitrary number here (from what I could tell), because the kernel > explicitly ensures that the syscall number being called is not larger > than SYS_MAXSYSCALL. This forces you to "steal" a syscall number > between 1 and SYS_MAXSYSCALL, no? -1 tells the kernel to find an unused syscall vector (there are several reserved for this purpose) and assign it for you. You then read the assigned number in userland using modstat(). (You can also get it from your 'offset' variable.. the kernel modifies it in the SYSINIT() invoked by SYSCALL_MODULE() and you could export it via a sysctl, etc.) > 3) I tried using a syscall number (115, deprecated vtrace), using it as > the offset when calling SYSCALL_MODULE, but the userland program calling > syscall(2) returned an error. I didn't research this too thoroughly. syscall_register() will only overwrite a system call whose function pointer is set to lkmnosys() or lkmressys(). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712171541.39959.jhb>