Re: single copy pipe/fifo
Manfred Spraul writes: > process 2 (on cpu 1) > read(fd,buf,64kB). > * reads the data > * now it must wake up, but it will return from the syscall, thus > wake_up_interruptible(). Oh, I see and thus the pre-kiovec case would be: process 2 (on cpu 1) read(fd, buf,64kb) * reads 4K * wake_up_interruptible_sync() * sleep() * reads 4K etc etc. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: single copy pipe/fifo
"David S. Miller" wrote: > > Manfred Spraul writes: > > * if you run 2 instances on a dual cpu P II/350 it's a big win, but if > > you run only one instance, then the bw_pipe processes will jump from one > > cpu to the other and it's only a small improvement (~+15%). > > wake_up_interruptible_sync is meant specifically to avoid > this cpu hopping behavior. > I use it whereever possible, but in this case it's not possible: pipe is empty. process 1 (on cpu 1) write(fd,buf,64kB). * creates kiobuf * sleeps. process 2 (on cpu 1) read(fd,buf,64kB). * reads the data * now it must wake up, but it will return from the syscall, thus wake_up_interruptible(). * wakeup notices that cpu1 is busy and sends process 1 to cpu 2 * read returns read(fd, buf, 64kB) * no data waiting, sleeps. process 1 (on cpu 2) * write returns write(fd, buf, 64 kB) * creates kiobuf * wake_up_interruptible_sync(), since it will schedule * schedule() but now schedule will pull process 2 to cpu 2 I haven't verified the sequence with kdb, but I'm certain that this happens. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: single copy pipe/fifo
Manfred Spraul writes: > * if you run 2 instances on a dual cpu P II/350 it's a big win, but if > you run only one instance, then the bw_pipe processes will jump from one > cpu to the other and it's only a small improvement (~+15%). wake_up_interruptible_sync is meant specifically to avoid this cpu hopping behavior. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: single copy pipe/fifo
Manfred Spraul writes: * if you run 2 instances on a dual cpu P II/350 it's a big win, but if you run only one instance, then the bw_pipe processes will jump from one cpu to the other and it's only a small improvement (~+15%). wake_up_interruptible_sync is meant specifically to avoid this cpu hopping behavior. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: single copy pipe/fifo
Manfred Spraul writes: process 2 (on cpu 1) read(fd,buf,64kB). * reads the data * now it must wake up, but it will return from the syscall, thus wake_up_interruptible(). Oh, I see and thus the pre-kiovec case would be: process 2 (on cpu 1) read(fd, buf,64kb) * reads 4K * wake_up_interruptible_sync() * sleep() * reads 4K etc etc. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: single copy pipe/fifo
"David S. Miller" wrote: Manfred Spraul writes: * if you run 2 instances on a dual cpu P II/350 it's a big win, but if you run only one instance, then the bw_pipe processes will jump from one cpu to the other and it's only a small improvement (~+15%). wake_up_interruptible_sync is meant specifically to avoid this cpu hopping behavior. I use it whereever possible, but in this case it's not possible: pipe is empty. process 1 (on cpu 1) write(fd,buf,64kB). * creates kiobuf * sleeps. process 2 (on cpu 1) read(fd,buf,64kB). * reads the data * now it must wake up, but it will return from the syscall, thus wake_up_interruptible(). * wakeup notices that cpu1 is busy and sends process 1 to cpu 2 * read returns read(fd, buf, 64kB) * no data waiting, sleeps. process 1 (on cpu 2) * write returns write(fd, buf, 64 kB) * creates kiobuf * wake_up_interruptible_sync(), since it will schedule * schedule() but now schedule will pull process 2 to cpu 2 I haven't verified the sequence with kdb, but I'm certain that this happens. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
