Date: Thu, 5 Jun 1997 19:24:16 +0200 From: lada@ws6303.gud.siemens.at (Hr.Ladavac) To: freebsd-hackers@FreeBSD.ORG, leec@adam.adonai.net Subject: Re: setting a really low priority... Message-ID: <199706051724.TAA09578@ws6423.gud.siemens.at>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 18:32:09 MET 1997 > Date: Thu, 5 Jun 1997 11:13:05 -0500 (CDT) > From: "Lee Crites (AEI)" <leec@adam.adonai.net> > To: freebsd-hackers@FreeBSD.ORG > Subject: setting a really low priority... > Mime-Version: 1.0 > X-Loop: FreeBSD.org > > > I'd like to have a few processes running on my system which will get, > and maintain, a fixed priority. > > Yes, I could use nice to change the initial priority. In fact, that is > how I am starting one other process on my system already. > > But this isn't really what I'm looking for. I'm more interested in > porting my real-time code to fbsd. > > [note: in this discussion, a 'higher' priority means the process is more > important, thus will be given more system resources, not that it's > priority number is larger -- which would be a 'lower' priority in my > discussion.] Take a look at rtprio manpage. There is such a beast in FreeBSD, and it behaves somewhat sysV4-ish (round robin scheduling of realtime processes, as long as they're runnable nobody else gets a chance, I'm not certain if they get pre-empted by a rt process of the same rtprio) There is a counterpart: idle priority processes which run only if everyone else is blocked. > > My main scheduler task needs to be fixed at a really high priority. It > also needs to have it's memory pinned and such, but that's another topic > for another time. When it runs, I want everyone else to shut up and > take notice. When it's done with one step it will go to sleep (via the > select() command) until time for the next step to happen. It is > currenlty running on several other machines (all aix :( ). It takes up > something less than 3% of the total system, but it needs virtually 100% > of the system when it is awake -- mostly for the scheduling. > > It takes up lots of memory (24meg of ram) and will run for a > loooooonnnnnnnnnnnnnnng time (24/365); use lots of system resources; > trigger events, send/recv socket data (14 tcp, 2 udp), manipulate > semaphores (up to 7) and shared memory (14 of the 24meg), etc, etc; > start and stop lots of other processes (38 of them). All of these are > things which traditionally move a processes priority down, down, down, > down... > > What I'd like is something like aix's fixed priority system. You can > use the 'regular' unix user priorities, which float around based upon > all sorts of esoteric things (like those listed above), but there are > also fixed priorities which stay fixed. As I recall (in aix) there are > 127 priority levels. The 'regular' user level priorities are, I believe > 30 - 69. There are higher fixed priorities 0 - 29 and lower fixed > priorities from 70 down to 127. > > Is there such an animal in FreeBSD? Can I tell a process to run at a > certain priority and have it stay there? Is there a way to tell a > process that it will only use a certain range of priorities? rtprio does that. It sets a process to a 1 fixed priority. > > I'm pretty sure that either of the above would not be a 'standard' unix > feature. I've tried scanning the code, but frankly didn't get very far. > (with no real string to grep for and/or no particular process to trace, > etc) It is a standard sysVr4 feature. > > Now, to toss another blob of goo into the soup... > > The main scheduler program uses pthreads. I've tried to get the pthread > scheduling/priority working on aix, but, alas, aix has implemented such > a *tinnny* subset of pthreads that thread priorities don't work very > well (if at all). So, not only would I like to be able to fix my > process's main thread priority to something fixed, I'd also like to be > able to do the same kind of thing for each thread. I don't know if libc_r/pthread on FreeBSD implements threads priority. I seem to vaguely recollect that MIT pthreads (FreeBSD implementation is a port/enhancement thereof) did such a thing, but high priority threads could not be pre-empted. Presently, FreeBSD pthreads are a user space library implementation on top of select() and non-blocking syscalls. Kernel threading is under development. > > Is the soup murky enough yet? Okay, I'll let it go at that, then. > > Anyway, any pointers you could give me would be greatly appreciated. > (even pointers to some "m's", code, etc) > Hope this helps. /Marino > Lee > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706051724.TAA09578>