> I'm not doing any prefetches in the code (if that is what you are
> talking about). The code just moves the pipe reader to the same
> CPU as the pipe writer (which is about to block). Certainly, the
> pipe reader could take advantage of any data written by the writer
> still being in the cache.
Hm, interesting. When Ingo removed the sync variants of wake_up he did
it believing the load balancer would handle the case. Apparently, at
least in this case, that assumption was wrong.
I agree with your earlier statement, though - this benchmark may be a
case where it shows up negatively but in general the balancing is
preferred. I can think of plenty of workloads where that is the case.
I also wonder if over time the load balancer would end up putting the
tasks on the same CPU. That is something the quick pipe benchmark would
not show.
> I'm not sure if 'synchronous' is still being passed all the way
> down to try_to_wake_up in your tree (since it was removed in 2.5).
> This is based off a back port of O(1) to 2.4.18 that Robert Love
> did. The rest of try_to_wake_up (the normal/common path) remains
> the same.
In 2.5 nor the 2.4 backport I did (what is in -ac) I don't think the
sync flag is being passed down since the functionality was removed. The
functions were rewritten I believe to not have that parameter at all.
It is just for pipes we previously used sync, no?
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/