Messages in this thread | | | Date | Mon, 31 Mar 1997 14:34:22 -0500 | From | "Theodore Y. Ts'o" <> |
| |
Subject: Re: Fix to make RLIMIT_DATA work with mmap and some questions about threads. Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091
Date: Fri, 28 Mar 1997 12:47:23 -0500 (EST) From: Greg Alexander <galexand@sietch.bloomington.in.us>
This is a simple patch to make RLIMIT_DATA do something useful with all allocated memory, including that which is mmap'd. It limits the amount of data PER USER, not per process as the old one did with brk(). For my purposes, per process was pretty pointless (we either stop them from running netscape at all, or we leave ourselves open to them running multiple netscapes. yucky). I have no idea what POSIX says about this, I'm only implementing what is useful for me.
POSIX doesn't specify this call, but the BSD definition of RLIMIT_DATA is per-process, and *unshared* data memory only.
What you implemented is also useful, although I'd suggest chosing a different resource name (say, RLIM_TOTAL_DATA) which does what you want.
Now for my threading question. Kernel threads are not pre-emptively multi-tasked, correct? Is there a plan for them to become pre-emptive by 2.2.0? I'm asking because I am using an ext2 compression patch (to enable chattr +c), but when it is under heavy usage, it will stay in kernel-mode for full seconds at a time on my 486/100. Could I make the compression be a kerneld-like (though I don't think kerneld's pipe is made for speed, is it?) daemon to handle this in userspace? Or would there be any way to start a pre-emptively task-switched, user-mode process from the kernel (better than having it start up in my /etc/rc.d scripts so that I can read, say a compressed init or whatever)?
No, kernel threads won't be pre-emptively switched; that would require making very fundamental changes in how the kernel works, and require a lot of fine-grained locking that's not necessary for non-SMP configurations.
The right thing to do is to fix the ext2 compression patch is that it periodically yields control to allow other threads to run.....
- Ted
| |