On Thu, 28 Oct 2004 [EMAIL PROTECTED] wrote:


Marco,

Wouldn't locking a process to a CPU cause the CPU to be idle during IO
waits and semaphore locks?  Even if you didn't lock each DB process to a
CPU, IO waits and locks for one session would stop processing on other
sessions managed by the same process.  Moving the scheduler to user space
seems to be reimplementing something the kernel knows best about.  Ever
worked with Ada tasking architectures?  Not pretty.

Quick answers: - there won't be any I/O wait; - there won't be any semaphore-related wait; - in my previous message, I've never mentioned the kernel scheduler; - no, the kernel knows nothing about PostgreSQL sessions.

It seems quite obvious to me that in the "one flow of execution per CPU"
model, all I/O is non-blocking. Everything is event-driven.

With session "scheduler" I was referring to the (generic) operation
of serving multiple sessions. On a 1-way system we do want to serve more
than one client. Right now, we relay on the kernel in choosing which one
to run at a given moment. We _do_ know better of it in many cases, see
the priority inversion problem mentioned a few days ago on the list.

The above is true for most N-ways systems, since we still want to serve
M sessions, where usually M >> N.

.TM.
--
      ____/  ____/   /
     /      /       /                   Marco Colombo
    ___/  ___  /   /                  Technical Manager
   /          /   /                      ESI s.r.l.
 _____/ _____/  _/                     [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to