Jamie Lokier wrote:
>
> This article talks about blocking due to disk I/O and those languages
> that, conceptually at least, use threads as the basic method of
> multiplexed I/O (e.g. Java).
>
[ ... ]
>
> For 100% efficiency, you need to always be ready to handle something,
> never an idle CPU. Even paging from disk shouldn't stop your program
> from doing other things.
>
> You would like that an event handler which was called from your select
> loop to be able to block, and for the select loop to call the other
> handlers in the meantime. One way to do that is demand allocation of
> stacks by multiple real threads.
>
[ ... ]
Good stuff. The key is "demand allocation", and it is not necessarily
the easy to accomplish, especially in a multiprocessor and
multiprogrammed environment where
1. you have multiple cpus, so you need 1 active kernel entity/cpu to keep
the cous busy; however, there may be no real parallelism in the
application to effectively make use of the kernel entity.
2. you have multiple users, so at an instant all the cpus are not
available for your application --- logically only some of the cpus
are yours, although you can timeshare under load, except at the risk
of sharing and polluting the caches by the threads of the unrelated
applications being timeshared onto the cpus.
Regardless, what you described in your article sounds a lot like
"scheduler activations" [1]. In an unshipped project, we tried to
work along similar lines in order to support Posix threads implemented
using the M on N model where you run into similar situations. The
lessons were that (a) pthread applications can have dramatic improvements
in performance (when some form of "demand allocation" is implemented).
(b) a lot of kernel support is needed.
ananth.
[1] "Scheduler Activations: Effective Kernel Support for the User-Level
Management of Parallelism", T.E.Anderson et.al., Symposium on
Operating Systems Principles (SOSP), 1991, pp. 95-109. I think
a later version also made it into TOCS (ACM Transactions on Computer
Systems Journal).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:07 EST