| Age | Commit message (Collapse) | Author |
|---|
|
- Split up run queues so that every cpu has one.
- Make setrunqueue choose the cpu where we want to make this process
runnable (this should be refined and less brutal in the future).
- When choosing the cpu where we want to run, make some kind of educated
guess where it will be best to run (very naive right now).
Other:
- Set operations for sets of cpus.
- load average calculations per cpu.
- sched_is_idle() -> curcpu_is_idle()
tested, debugged and prodded by many@
|
|
ok deraadt
|
|
fork(), i worry about it a lot but cannot prove yet that sleeping there
is bad. Anyways, this change makes us never sleep in that area -- the
memory needed is allocated ealier like the ptrace state. tested by many
developers.
|
|
in case we need it. the idea is to try to get rid of some potential
sleeps..
ok tedu
|
|
Put a reference count in struct process to prevent use-after-free
if the main thread reaches the reaper ahead of some other thread
in the process. Use the reference count to update the user process
count correctly when changin real uid.
"please re-commit before something else nasty comes in" deraadt@
|
|
|
|
if the main thread reaches the reaper ahead of some other thread
in the process.
ok art@ tedu@
|
|
free things when exiting a threaded proc. from philip guenther
|
|
|
|
- Move the functionality of choosing a process from cpu_switch into
a much simpler function: cpu_switchto. Instead of having the locore
code walk the run queues, let the MI code choose the process we
want to run and only implement the context switching itself in MD
code.
- Let MD context switching run without worrying about spls or locks.
- Instead of having the idle loop implemented with special contexts
in MD code, implement one idle proc for each cpu. make the idle
loop MI with MD hooks.
- Change the proc lists from the old style vax queues to TAILQs.
- Change the sleep queue from vax queues to TAILQs. This makes
wakeup() go from O(n^2) to O(n)
there will be some MD fallout, but it will be fixed shortly.
There's also a few cleanups to be done after this.
deraadt@, kettenis@ ok
|
|
bug in the code, but as soon as I try to fix it, it seems to trigger
some other bugs. Instead of trying to figure out what's going on
while everyone suffers, it's better to back out and figure out
the bugs outside the tree.
|
|
have cpu_info now, so kill the option.
eyeballed by jsg@ and grange@
|
|
leave macros behind for now to keep the commit small
ok art beck miod pedro
|
|
a new struct. Instead of doing a huge rename and deal with the fallout
for weeks, like other projects that need no mention, we will slowly and
carefully move things out of struct proc into a new struct process.
- Create struct process and the infrastructure to create and remove them.
- Move threads in a process into struct process.
deraadt@, tedu@ ok
|
|
Instead, keep the proc pointer in it and put the selinfo on a list
in struct proc in selrecord. Then clean up the list when leaving
sys_select and sys_poll.
miod@ ok, testing by many, including Bobs spamd boxes.
|
|
it's a good idea to use atomic.h operations on it. This mechanic
change updates all bit operations on p_flag to atomic_{set,clear}bits_int.
Only exception is that P_OWEUPC is set by MI code before calling
need_proftick and it's automatically cleared by ADDUPC. There's
no reason for MD handling of that flag since everyone handles it the
same way.
kettenis@ ok
|
|
later when more of it's resources have been allocated and thus
kill(2)ing such a process has more predictable results.
now w/ a couple of kettenis remarks; kettenis@ miod@ ok
|
|
should never be referenced outside the context of the process to which
this stack belongs unless we do the PHOLD/PRELE dance. Loads of code
doesn't follow the rules here. Instead of trying to track down all
offenders and fix this hairy situation, it makes much more sense
to not swap kernel stacks.
From art@, tested by many some time ago.
|
|
|
|
timeouts earlier as we can sleep later and get signals and exit and cause all kinds of hell; pedro@ ok
|
|
discussed with a few, ok tedu@
|
|
|
|
|
|
uses rfork(RFTHREAD) to create threads, which are presently processes
that are a little more tightly bound together. several new syscalls
added to facilitate a userland thread library.
all conditional on RTHREADS, currently disabled.
ok deraadt
|
|
In fork1(), setup the p_{prof,virt}_to timeouts _before_ putting the process
on the runqueue. Since SCHED_UNLOCK() can cause pre-emption, it is possible
(with the old code) for the newly created process to run and become curproc
before the timeouts were set. If itimers are set early, and you're unlucky,
hardclock() might fire at this time and attempt timeout_add() on the unset
timeouts, leading to "panic: timeout_add: not initialized".
deraadt@, miod@ ok
|
|
ok miod@
|
|
|
|
everyone for the prompt review and ok of this work ;-) Yeah, that includes me
too, or maybe especially me. I am sorry.
Change the sched_lock to a mutex. This fixes, among other things, the infamous
"telnet localhost &" problem. The real bug in that case was that the sched_lock
which is by design a non-recursive lock, was recursively acquired, and not
enough releases made us hold the lock in the idle loop, blocking scheduling
on the other processors. Some of the other processors would hold the biglock though,
which made it impossible for cpu 0 to enter the kernel... A nice deadlock.
Let me just say debugging this for days just to realize that it was all fixed
in an old diff noone ever ok'd was somewhat of an anti-climax.
This diff also changes splsched to be correct for all our architectures.
|
|
ok deraadt miod markus
|
|
and have it stall on a semaphore. This allows all kthread creations which
could have been requested during autoconf to be processed before root
is mounted as well.
This causes umass devices attached to any usb with flags 1 (such as on macppc)
to configure properly instead of panicing the kernel at mountroot time.
From NetBSD; tested by various.
|
|
|
|
sends SIGVTALRM and SIGPROF to the process if they had. There is a big
problem with calling psignal from hardclock on MULTIPROCESSOR machines
though. It means we need to protect all signal state in the process
with a lock because hardclock doesn't obtain KERNEL_LOCK. Trying to
track down all the tentacles of this quickly becomes very messy. What
saves us at the moment is that SCHED_LOCK (which is used to protect
parts of the signal state, but not all) happens to be recursive and
forgives small and big errors. That's about to change.
So instead of trying to hunt down all the locking problems here, just
make hardclock not send signals. Instead hardclock schedules a timeout
that will send the signal later. There are many reasons why this works
just as good as the previous code, all explained in a comment written
in big, friendly letters in kern_clock.
miod@ ok noone else dared to ok this, but noone screamed in agony either.
|
|
encapsulating all such access into wall-defined functions
that makes sure locking is done as needed.
It also cleans up some uses of wall time vs. uptime some
places, but there is sure to be more of these needed as
well, particularily in MD code. Also, many current calls
to microtime() should probably be changed to getmicrotime(),
or to the {,get}microuptime() versions.
ok art@ deraadt@ aaron@ matthieu@ beck@ sturm@ millert@ others
"Oh, that is not your problem!" from miod@
|
|
|
|
Introduce the cpu_info structure, p_cpu field in struct proc and global
scheduling context and various changed code to deal with this. At the
moment no architecture uses this stuff yet, but it will allow us slow and
controlled migration to the new APIs.
All new code is ifdef:ed out.
ok deraadt@ niklas@
|
|
|
|
|
|
from form@pdp-11.org.ru via mpech. ok millert
|
|
other projects' implementations.
|
|
when there is a fork bomb going on. From NetBSD (jdolecek)
|
|
|
|
use them to correctly emulate linux brk.
update to TNF copyright in linux_exec.c.
from netbsd, mostly from a diff by Kurt Miller in pr3318.
this should fix java. no regressions in testing by kurt and sturm@.
be prepared for "proc size mismatch" -- recompile ps and friends.
ok deraadt@
|
|
rescinded 22 July 1999. Proofed by myself and Theo.
|
|
been fully initialized. Otherwise the scheduler and other things can
accidentally stumble into semi-initialized processes and strange things
can happen. This also requires us to do systrace attachment a bit later.
Debugging help from fgs@
|
|
|
|
|
|
First we check for running out of processes (nprocs variable) before we
continue with the fork, then we do various calls that might sleep (and
allow other forks to start and pass that check), then we increase that
variable. This could allow processes to be created past the limit.
Second is that we don't decrease the the process count for this uid
if the stack allocation fails. So a user could run out of processes
he's allowed to run without actually having them.
miod@ ok
|
|
okay deraadt@
|
|
|
|
Don't assume that the stack is on the top of user address space.
And don't assume that the stack grows down.
|
