[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mach's in-kernel scheduling
From: |
Igor Khavkine |
Subject: |
Re: Mach's in-kernel scheduling |
Date: |
Mon, 20 Aug 2001 17:46:16 -0400 |
"Thomas Bushnell, BSG" wrote:
>
> Igor Khavkine <i_khavki@alcor.concordia.ca> writes:
>
> > It is my understanding that Mach supports "in-kernel" threads,
> > i.e. threads that run concurrently in the kernel, not being visible
> > in userspace.
> >
> > The first kernel thread, after it does all the initialization and starts
> > userspace initialization, runs vm_pageout() to become the garbage
> > collection daemon.
>
> Please don't call this garbage collection, it isn't.
I was mostly looking at the zone allocation code, and there is a
function that calls itself consider_zone_gc() which is supposed do
what appears to be garbage collection. I traced it's invocation to
the pageout-daemon, that's why I called that whole thread the
garbage collection daemon. I guess that's only part of it.
> > Turns out that zones are susceptible to garbage collection. However,
> > I'm really clueless about Mach's way of scheduling these "in-kernel"
> > threads. When does this GC thread actually get to run, can it run
> > concurrently while a system call is executed, or does it need
> > a yield statement somewhere?
>
> It's a thread just like any other. It's in the same state as if a
> system call started doing things but never returned.
>
> Threads in kernel mode like this (either this one, or threads during
> syscall execution) are not pre-emptively scheduled. Instead, they
> must explicitly block to relinquish the CPU.
I see, that makes sense. I guess thread_block() is like a yield statement.
My primary concern here is whether or not the pageout thread is called
or not when there is a shortage or resources. For example I dont see
any indication that the pageout thread is invoked when zalloc is unable
to allocate any more memory for some zone, although it is possible
that some kernel resources will be freed once the zone garbage collector
has run. Is there something I'm missing, or is there a valid reason
for panicing when virtual memory is exhausted instead of trying to free
up some which is unused?
Igor