Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi All, I appreciate if somebody can tell me why spinlock and semaphore are utilized to protect work queue in drbd worker thread. I have some performance issue with regard to the use of this semaphore. Specifically, down_interruptible takes too long to be waked up. Here is the detail: In drbd_worker.c, function int drbd_worker(struct drbd_thread *thi). int drbd_worker(struct drbd_thread *thi) { .... if (down_trylock(&mdev->data.work.s)) { mutex_lock(&mdev->data.mutex); if (mdev->data.socket && !mdev->net_conf->no_cork) drbd_tcp_uncork(mdev->data.socket); mutex_unlock(&mdev->data.mutex); intr = down_interruptible(&mdev->data.work.s); mutex_lock(&mdev->data.mutex); if (mdev->data.socket && !mdev->net_conf->no_cork) drbd_tcp_cork(mdev->data.socket); mutex_unlock(&mdev->data.mutex); } .... w = NULL; spin_lock_irq(&mdev->data.work.q_lock); ERR_IF(list_empty(&mdev->data.work.q)) { /* something terribly wrong in our logic. * we were able to down() the semaphore, * but the list is empty... doh. * * what is the best thing to do now? * try again from scratch, restarting the receiver, * asender, whatnot? could break even more ugly, * e.g. when we are primary, but no good local data. * * I'll try to get away just starting over this loop. */ spin_unlock_irq(&mdev->data.work.q_lock); continue; } ... } I tried to get rid of semaphore in above as well as in drbd_queue_work in drbd_ini.h. Somehow, the code breaks ugly. I guess I still don`t get the design rational here. Any help is appreciated. Thanks Ben Commit yourself to constant self-improvement -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100929/44872365/attachment.htm>