Re: status of KSE merge

2002-07-05 Thread Peter Wemm

Julian Elischer wrote:

 At this time I have no information on any apps that fail to work (that did
 work before KSE).
 
 The signal flakiness is still present but at least people can get work
 done. I will work on this next (though signal experts are welcome to
 try their hand as well.. (in fact any beginners who want to jump inat the 
 deep end of the pool can guarantee a near-drowning-experience by trying
 to understand signals).

Some news:  syscall restart after signals is broken.  This is responsible
for a lot of the ^Z/fg problems as well as some applications failing when
their timer signals cause IO problems.

Test case:
peter@overcee[12:49pm]~-125 cat restart.sh
#! /tmp/44sh
echo -n Type something: 
read foo
echo You typed: \$foo\
peter@overcee[12:49pm]~-126 ./restart.sh 
Type something: foo
You typed: foo
peter@overcee[12:49pm]~-127 ktrace ./restart.sh 
Type something: ^Z
[1]  + Suspended ktrace ./restart.sh
peter@overcee[12:49pm]~-128 fg
ktrace ./restart.sh
You typed: 
peter@overcee[12:49pm]~-129 kdump -R
[...]
  1091 44sh 0.61 CALL  write(0x1,0x80c4000,0x10)
  1091 44sh 0.29 GIO   fd 1 wrote 16 bytes
   Type something: 
  1091 44sh 0.000198 RET   write 16/0x10
  1091 44sh 0.000187 CALL  read(0,0xbfbff2f3,0x1)
  1091 44sh 3.054434 RET   read -1 errno 4 Interrupted system call
  1091 44sh 0.000695 CALL  write(0x1,0x80c4000,0xe)
  1091 44sh 0.25 GIO   fd 1 wrote 14 bytes
   You typed: 
   
  1091 44sh 0.000254 RET   write 14/0xe
[..]

The errno 4 - interrupted system call should not happen.  read returns
ERESTART internally on the signal catch, and the syscall() function in trap.c
is supposed to back up the eip which causes the syscall to be rerun.

I have not looked at the code yet.  This is responsible for things like
vipw failing after ^Z/fg (editor=vi), mergemaster failing on ^Z/fg etc.
(it was mergemaster that tipped me off on this.)

Applications that use interval timers would be suffering from this pretty
badly.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: status of KSE merge

2002-07-05 Thread David Xu

the following patch can fix the bug, but for KSE programs, it may not be a
best solution, KSE programs signal handling is on going...

--- kern_synch.cWed Jul  3 17:15:20 2002
+++ kern_synch.c.newSat Jul  6 10:36:22 2002
@@ -537,8 +537,7 @@
PROC_LOCK(p);
sig = cursig(td);
if (thread_suspend_check(1)) {
-   sig = EINTR;
-   rval = EINTR;
+   sig = SIGSTOP; 
}
mtx_lock_spin(sched_lock);
PROC_UNLOCK(p);


-David Xu

- Original Message - 
From: Peter Wemm [EMAIL PROTECTED]
To: Julian Elischer [EMAIL PROTECTED]
Cc: FreeBSD current users [EMAIL PROTECTED]
Sent: Saturday, July 06, 2002 3:52 AM
Subject: Re: status of KSE merge 


 Julian Elischer wrote:
 
  At this time I have no information on any apps that fail to work (that did
  work before KSE).
  
  The signal flakiness is still present but at least people can get work
  done. I will work on this next (though signal experts are welcome to
  try their hand as well.. (in fact any beginners who want to jump inat the 
  deep end of the pool can guarantee a near-drowning-experience by trying
  to understand signals).
 
 Some news:  syscall restart after signals is broken.  This is responsible
 for a lot of the ^Z/fg problems as well as some applications failing when
 their timer signals cause IO problems.
 
 Test case:
 peter@overcee[12:49pm]~-125 cat restart.sh
 #! /tmp/44sh
 echo -n Type something: 
 read foo
 echo You typed: \$foo\
 peter@overcee[12:49pm]~-126 ./restart.sh 
 Type something: foo
 You typed: foo
 peter@overcee[12:49pm]~-127 ktrace ./restart.sh 
 Type something: ^Z
 [1]  + Suspended ktrace ./restart.sh
 peter@overcee[12:49pm]~-128 fg
 ktrace ./restart.sh
 You typed: 
 peter@overcee[12:49pm]~-129 kdump -R
 [...]
   1091 44sh 0.61 CALL  write(0x1,0x80c4000,0x10)
   1091 44sh 0.29 GIO   fd 1 wrote 16 bytes
Type something: 
   1091 44sh 0.000198 RET   write 16/0x10
   1091 44sh 0.000187 CALL  read(0,0xbfbff2f3,0x1)
   1091 44sh 3.054434 RET   read -1 errno 4 Interrupted system call
   1091 44sh 0.000695 CALL  write(0x1,0x80c4000,0xe)
   1091 44sh 0.25 GIO   fd 1 wrote 14 bytes
You typed: 

   1091 44sh 0.000254 RET   write 14/0xe
 [..]
 
 The errno 4 - interrupted system call should not happen.  read returns
 ERESTART internally on the signal catch, and the syscall() function in trap.c
 is supposed to back up the eip which causes the syscall to be rerun.
 
 I have not looked at the code yet.  This is responsible for things like
 vipw failing after ^Z/fg (editor=vi), mergemaster failing on ^Z/fg etc.
 (it was mergemaster that tipped me off on this.)
 
 Applications that use interval timers would be suffering from this pretty
 badly.
 
 Cheers,
 -Peter
 --
 Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
 All of this is for nothing if we don't go to the stars - JMS/B5




__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: status of KSE?

2001-04-01 Thread Adrian Chadd

On Fri, Mar 16, 2001, David Xu wrote:

 I know KSE is not related to SMP and will run on UP. my primary
 idea is want to run parellel I/O task in same process with pthread,
 simply because FreeBSD pthread does not allow me to do multipile
 I/O tasks at same time on disk file, of course, it is also conflicted
 with SYSV IPC, so I think of KSE. I don't care about SMP, CPU is
 enough fast now, I have already seen 1.3G hz CPU, how fast! I think
 Intel and AMD can very easy to double their CPU clock, hope I can see
 3Ghz CPU in next year. I really do think KSE should work before SMP,
 but it is obvious not. think about Apache 2.0, it is already
 multi-threaded, FreeBSD pthread will be blocked at disk I/O, it is very
 bad for Apache 2.0 .

One could theoretically hack the pthreads port into using either
external processes for disk IO, or the aio_ routines. Both of these
would suffice. (Note that aio_ only does read/write/lseek, whilst
open() and close() are still sync, and open() can take quite a while..)



Adrian


-- 
Adrian Chadd"Programming is like sex:
[EMAIL PROTECTED]   One mistake and you have to support for
a lifetime." -- rec.humor.funny


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: status of KSE?

2001-03-16 Thread Julian Elischer

Peter Pentchev wrote:
 
 On Fri, Mar 16, 2001 at 12:59:24PM +0800, David Xu wrote:
  Hello Julian,
 
  Friday, March 16, 2001, 12:18:15 PM, you wrote:
 
  JE David Xu wrote:
  
  I wonder status of KSE, I am dreaming rewrite our application
   server using kqueue+pthread(KSE), current, we use poll()+pthread
   because pthread does not work with kqueue at present.
  
   --
   Best regards,
   David Xu
 
  JE KSE is not into coding yet.
  JE we have a basic design and have soem documents but
  JE have been waiting for the SMPng stuff to settle a bit before we
  JE hit the kernel with a second huge change.
 
  JE It will not be ready for a long time. do not assume that it
  JE will be ready for when you need it becasue it will not.
 
  I know KSE is not related to SMP and will run on UP. my primary
  idea is want to run parellel I/O task in same process with pthread,
  simply because FreeBSD pthread does not allow me to do multipile
  I/O tasks at same time on disk file, of course, it is also conflicted
  with SYSV IPC, so I think of KSE. I don't care about SMP, CPU is
  enough fast now, I have already seen 1.3G hz CPU, how fast! I think
  Intel and AMD can very easy to double their CPU clock, hope I can see
  3Ghz CPU in next year. I really do think KSE should work before SMP,
  but it is obvious not. think about Apache 2.0, it is already
  multi-threaded, FreeBSD pthread will be blocked at disk I/O, it is very
  bad for Apache 2.0 .
 
 I believe Julian's SMP-related comments were referring to the fact that
 SMP development has rendered the -current kernel somewhat unstable at
 times (to say the least).  KSE-related work would introduce yet another
 probable path for instabilities, and the developers prefer dealing with
 one huge monster at a time.  There is also the fact that KSE work shall
 most probably touch many places in the kernel that SMP development also
 touches - yet another reason to postpone KSE until SMP is kind-of do

That is it. 
Having said that,
Jason and I have patches that start on the first steps towards KSE.
That is, the breaking up of the present monolithic 'process' structure.
given current slight increases in stablility in -current/SMP
I am currently thiunking about whether these changes can start to be added 
soon.

I will also be looking at updating and expanding the KSE documant that Jason put
out.

 
 G'luck,
 Peter
 
 --
 You have, of course, just begun reading the sentence that you have just finished 
reading.
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-hackers" in the body of the message

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
--- X_.---._/  
v

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: status of KSE?

2001-03-16 Thread Peter Pentchev

On Fri, Mar 16, 2001 at 12:59:24PM +0800, David Xu wrote:
 Hello Julian,
 
 Friday, March 16, 2001, 12:18:15 PM, you wrote:
 
 JE David Xu wrote:
  
 I wonder status of KSE, I am dreaming rewrite our application
  server using kqueue+pthread(KSE), current, we use poll()+pthread
  because pthread does not work with kqueue at present.
  
  --
  Best regards,
  David Xu
 
 JE KSE is not into coding yet.
 JE we have a basic design and have soem documents but
 JE have been waiting for the SMPng stuff to settle a bit before we
 JE hit the kernel with a second huge change.
 
 JE It will not be ready for a long time. do not assume that it
 JE will be ready for when you need it becasue it will not.
 
 I know KSE is not related to SMP and will run on UP. my primary
 idea is want to run parellel I/O task in same process with pthread,
 simply because FreeBSD pthread does not allow me to do multipile
 I/O tasks at same time on disk file, of course, it is also conflicted
 with SYSV IPC, so I think of KSE. I don't care about SMP, CPU is
 enough fast now, I have already seen 1.3G hz CPU, how fast! I think
 Intel and AMD can very easy to double their CPU clock, hope I can see
 3Ghz CPU in next year. I really do think KSE should work before SMP,
 but it is obvious not. think about Apache 2.0, it is already
 multi-threaded, FreeBSD pthread will be blocked at disk I/O, it is very
 bad for Apache 2.0 .

I believe Julian's SMP-related comments were referring to the fact that
SMP development has rendered the -current kernel somewhat unstable at
times (to say the least).  KSE-related work would introduce yet another
probable path for instabilities, and the developers prefer dealing with
one huge monster at a time.  There is also the fact that KSE work shall
most probably touch many places in the kernel that SMP development also
touches - yet another reason to postpone KSE until SMP is kind-of done.

G'luck,
Peter

-- 
You have, of course, just begun reading the sentence that you have just finished 
reading.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message