> > A file is believed to be a bit slower due to fragmentation and some other > issues. People often create swap partitions without any thought. I have not > seen any benchmarks though. That's fine. In Windows, I guess this problem is partially solved by allocating contiguous regions towards the end of the disk, for the so called page-file. > > A swap device cannot exist over NFS. You can only have a swap device file > which points to a local block device. But there is a thing called "network > block device" which can to such a thing. I guess that more or less answers my question. i.e., a device existing over a network. > cases the system might not be able to swap out memory and trigger the oom > killer... Will there be enough memory for the oom killer? :-) I mean, oom-killer is a function, that would require some stack space. It has to decide which process to kill, and then, kill it. Is it guaranteed that this killer doesn't need memory? > > There is a thing "plan 9 file system" in the Linux kernel, too, but I have > never used it. > -Michi Thanks, I will check it out. This was the reason I had the question: kmalloc uses a GFP_NOIO flag, which makes sure that IO won't occur when memory is allocated. There is also another flag, called, GFP_NOFS, which guarantees that no file system calls will be made. How do the two flags differ? The point is that -- NOFS might initiate disk operations, if swap were a device, to fulfill a memory request by (say) flushing some block caches. NOIO will make sure this doesn't happen. But, consider the following situation: * Swap device is over a network * kmalloc(size, GFP_NOFS) is called The question arose when I wondered about this: Does having a swap device guarantee that no FS operations will take place, during a kalloc()? It seems like in the above case, a FS operaiton will be involved, via NFS. And finally, as far as the host system is concerned, is a swap device over NFS equivalent to having a swap file over NFS? Apologies if the way I put the question is confusing! -- Vimal -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
