On Thu, Aug 18, 2005 at 12:24:51 +0000, Vincenzo Mallozzi wrote: > On Wednesday 17 August 2005 21:54, Jan Hudec wrote: > > On Wed, Aug 17, 2005 at 12:32:11 +0000, Vincenzo Mallozzi wrote: > > > > I've also expanded swap memory to include all of the data structures my > module > > > creates (up to 3.7 GB). > > > > And did you also teach the module to swap the data? > > No, I'm not because initially I just think that also kernel data can be > swapped out. And then I read from "Understanding Linux Kernel" and other > books that the swapout() function acts only on processes address space. That's not actually precise. It acts on pages in page cache. You should be able to set up pages in page cahce, either file-backed or anonymous, put stuff into them and have them saved/swapped to disk as any other page-cache pages. > > Again, why do the data need to be in kernel. I am not saying there is no > > reason for it, but could you explain what you are doing a bit? There may be > > another solution. > > Oh, yes. There's no reason for maintaining data in kernel-space but I know > that allocation , from within a kernel module, happens by means of kmalloc, > vmalloc and get_free_pages functions but all of these allocate memory in > kernel space as they are called from within a kernel module. I mean can't you just pass the data to a userland process. > Now, I briefly explain what I'm doing. > > I'm creating a kernel module by which I do various checkpoint of some threads > I'm monitoring. > I've to create various system state, each of which contains a snapshot of the > system at any instant. In other word, I've two data structures, one > containing usefull info about task_struct of each thread and the other > containing usefull information about shared memory descriptor (and related > vmas). this two data structures are contained in a greter data structures the > describes each state of the system. > I've to create such a state when some events occur (I'll not describe the > events that have to occur. they're not important for the sake of module > description). > After I've created such a state, I've to push it on a stack. The problem is > that after the creation of some states, system memory will going to empty. > So I need to flush the contents of the stack on disk and consequently free > memory. > I do it monitoring the memory used by the system. Ok. Sounds sane. There is one question left: Where will the data go from the "stack"? > I hope I've well explained my problem but I don't know how I can allocate this > memory in Userland from within a module. Well, I meant you would pass the data to userland helper. If the data are going to userland later anyway, you can as well do it earlier and save yourself the trouble allocating kernel memory. However if the data are never going to leave the kernel, read on, as you _should_ be able to use swappable memory from kernel. There may be a better way, without creating files, but with files it can surely work. First, you can read and write files from kernel, going directly to the methods of struct file (the file_operations structure). You can also go even more directly via that file's address_space (and it's readpage, prepare_write and commit_write and accessing pages directly), avoiding the copy in read/write. This only works if the file uses generic_file_read/generic_file_write, but most filesystems do. Now any page in file may be written to that file and discarded, with exception of files on tmpfs, that should be swapped (as tmpfs has no permanent storage). So you can open a file in kernel and write to it. You may be able to just allocate struct address_space manually, provide it with the fuctions mostly copied over from tmpfs and get it to work, but it's likely you will also have to create a dummy file, dentry, inode and superblock, in which case you can just create an instance of tmpfs. It's not easiest thing to do. It will also mean a slow-down (as you have to map and unmap the pages in kernel memory for each access). You have to take care of the fact, that the page you want to write to may not be present in memory, so the access may block and thus must be done from process context and does not provide upper bound on time to complete. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
