Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Nov 1999 17:48:43 -0500
From:      "Daniel M. Eischen" <eischen@vigrid.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org
Subject:   Re: Threads goals  version III
Message-ID:  <38220D4B.9BEAFCDB@vigrid.com>
References:  <199911041804.LAA18253@usr06.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> 4)      Abuse of kernel threads in order to compete as N kernel
>         schedulable entities with respect to other processes in
>         the system
> 
>         This is a dodge to avoid supporting or implementing
>         scheduler callses for the class of problems that really
>         need scheduler classes, in the hopes that a certain
>         unfair competition ratio "will be enough".

4a) Use of kernel threads to compete in different scheduler
    classes?

We have a MT application under Solaris with a few threads bound
to LWPs and placed in the real-time scheduler class.  These threads
are carefully crafted to not chew up the CPU, but to respond in a
timely manner to events.  The rest of the threads in the application
are not in the real-time class (and we don't want them to be)

I think that what you're implying in 4, is that an application
should place itself in the proper scheduling class/priority to
"achieve unfair competition".  My concern is that we not restrict
the kernel scheduling class to be at the process level, but we
allow for fine grained control of the threads within a process.

Dan Eischen
eischen@vigrid.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38220D4B.9BEAFCDB>