On 04/01/2012 07:12 PM, MORITA Kazutaka wrote: > At Sun, 01 Apr 2012 18:31:24 +0800, > Liu Yuan wrote: >> >> On 04/01/2012 04:47 PM, MORITA Kazutaka wrote: >> >>>>> Let's leave aside IO req that are just queued, not issued. >>>>> >>>>> Even with separate queues, seems that we need to wait for completion of >>>>> infly IOs. No? >>> Yes. >>> >> >> >> So either way, we need to wait for infly io. This brings problem, since >> queuing is processed in main thread. > > Yes, but succeeding membership messages can be processed immediately > because we can skip I/O requests in cpg_event_siblings, no? > >> >>>>> >>>>> So one queue with higher priority placement of notify & confchg event, >>>>> we could have a working solution. >>> Yes, I guess it will work. I thought it is simpler to use two queues >>> than traversing one queue to find the proper placement, though. >> >> >> Placement is very simple, that is why I used a single queue, just >> inserting it at head, since if there is no infly IO hanging around, we >> are guaranteed that the event in the head of the queue will be processed >> immediately. > > But some nodes may have outstanding I/Os but the others may not... > > I really don't understand how all nodes process events in the same > order if we add them to the head of the FIFO queue. Some nodes can > process messages in the delivered order, but the other ones can do > them in the reverse order if there are pending messages. I think it > is not good at all to process messages in the different order from the > multicasted order. > > Maybe, I'm missing some points. If it is not difficult to implement > those, I'd like to see the code. > Hmm, maybe we are talking the same thing with different focus. I give it a second thought, I'll try two queue, since it might need smallest changes. Thanks, Yua |