From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 7 11:52:57 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D6F16A418 for ; Fri, 7 Dec 2007 11:52:57 +0000 (UTC) (envelope-from gheinig@marvell.com) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF87413C468 for ; Fri, 7 Dec 2007 11:52:57 +0000 (UTC) (envelope-from gheinig@marvell.com) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 8FC232C08A; Fri, 7 Dec 2007 03:52:57 -0800 (PST) Received: from SKGExch01.marvell.com ([10.9.116.16]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 03:52:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2007 12:52:54 +0100 Message-ID: <4D634BCFD1A2144ABECC75FF512D7A9001DF60C0@SKGExch01.marvell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Large array in KVM Thread-Index: Acg4w6dlxrIdgQ79Ry+UfTbPRFT5sgAAvVOg From: "Gerald Heinig" To: "Jeremy Chadwick" X-OriginalArrivalTime: 07 Dec 2007 11:52:57.0344 (UTC) FILETIME=[B56BB000:01C838C7] Cc: freebsd-hackers@freebsd.org, Sonja Milicic Subject: RE: Large array in KVM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 11:52:57 -0000 > 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. >=20 > Somewhat related question: >=20 > 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: >=20 > 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. >=20 > 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? >=20 > 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. >=20 > As this was the first (only?) kernel module I attempted to write, it's > safe to say I'm missing some key knowledge, hence my question. :-) I've only ever written device drivers; I haven't yet implemented a system call so unfortunately I can't answer your questions, sorry. I do know that system calls have to deal with the possibility of pages being non-resident, and this prompted my suggestions above. Cheers, Gerald