Hi!

A remark on semop(): From what I've read, the RAM-based POSIX semaphores are 
much 
faster than the SysV semop() kernel-based semaphores. If the processes use some 
shared memory it may be worth trying the POSIX semaphores, especially when it 
seems that semop() is a bottle-neck. Maybe there are even faster Linux-specific 
solutions.

See sem_init(), sem_destroy(), sem_post(), sem_wait(), etc. ...

Regards,
Ulrich


On 18 Oct 2009 at 15:02, Erez Zilber wrote:

> 
> I took a look at dolog() & log_flush(). Both use semop. If I
> understood the semop man page correctly, using a negative sem_op value
> means 'down' (i.e. enter a critical section). Using a positive sem_op
> value means 'up' (i.e. leave the critical section). According to that,
> it looks to me that the syslog calls in dolog() & log_flush() print
> incorrect information. Am I right?
> 
> Another (bigger) problem - from time to time, when I run 'iscsiadm -m
> node -U all', it never returns. When I ran 'echo t >
> /proc/sysrq-trigger', I got the following:
> 
> iscsid        S 0000000000000000     0  8441      1          8442 24234 
> (NOTLB)
> Oct 15 14:46:29 b73 kernel:  ffff81012e28dd28 0000000000000086
> 0000000000000000 000000007fb18660
> Oct 15 14:46:29 b73 kernel:  ffff81012e28de48 000000000000000a
> ffff81003e3bd080 ffff810143b85100
> Oct 15 14:46:29 b73 kernel:  0000912e761c6b46 0000000000002973
> ffff81003e3bd268 00000006800547f7
> Oct 15 14:46:29 b73 kernel: Call Trace:
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8014b5d4>] __next_cpu+0x19/0x28
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8008bdf5>] 
> find_busiest_group+0x20d/0x621
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8011c267>] sys_semtimedop+0x627/0x720
> Oct 15 14:46:29 b73 kernel:  [<ffffffff80063097>] thread_return+0x62/0xfe
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8004dd1b>] lock_hrtimer_base+0x26/0x4c
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8003a65a>]
> hrtimer_try_to_cancel+0x4a/0x53
> Oct 15 14:46:29 b73 kernel:  [<ffffffff80059d69>] hrtimer_cancel+0xc/0x16
> Oct 15 14:46:29 b73 kernel:  [<ffffffff80063db6>] do_nanosleep+0x47/0x70
> Oct 15 14:46:29 b73 kernel:  [<ffffffff80059c56>] hrtimer_nanosleep+0x58/0x118
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8005d28d>] tracesys+0xd5/0xe0
> Oct 15 14:46:29 b73 kernel:
> Oct 15 14:46:29 b73 kernel: iscsid        S ffffffff800627ba     0
> 8442      1         29016  8441 (NOTLB)
> Oct 15 14:46:29 b73 kernel:  ffff81012fa65d28 0000000000000086
> 0000000000000000 ffff8101a0282100
> Oct 15 14:46:29 b73 kernel:  ffff81012fa65e10 000000000000000a
> ffff81067683d040 ffff81017b7fb080
> Oct 15 14:46:29 b73 kernel:  0000912e761c6007 00000000000028ca
> ffff81067683d228 000000018003d267
> Oct 15 14:46:29 b73 kernel: Call Trace:
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8011c267>] sys_semtimedop+0x627/0x720
> Oct 15 14:46:29 b73 kernel:  [<ffffffff80058e3a>]
> inet_stream_connect+0x225/0x236
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8021a0a8>] sock_getsockopt+0x326/0x348
> Oct 15 14:46:29 b73 kernel:  [<ffffffff80032e39>] lock_sock+0xa7/0xb2
> Oct 15 14:46:29 b73 kernel:  [<ffffffff80217b32>] sys_connect+0x7e/0xae
> Oct 15 14:46:29 b73 kernel:  [<ffffffff8005d28d>] tracesys+0xd5/0xe0
> 
> It looks like both iscsid processes are waiting for a semaphore.
> 
> Later, when I ran strace, I got the following logs (because semop was
> interrupted):
> 
> Oct 15 14:53:28 b73 iscsid: semop up failed 4
> Oct 15 14:53:56 b73 iscsid: semop down failed
> Oct 15 14:54:27 b73 iscsid: semop up failed 4
> 
> BTW - why do we always have 2 iscsid processes?
> 
> Thanks,
> Erez
> 
> > 



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to