On Friday 08 February 2002 10:39 pm, Andreas Dilger wrote:
> On Feb 08, 2002 18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)
>
> I don't see why everyone who is using BK is expecting Linus to do a pull.
> In the non-BK case, wasn't it always a "push" model, and Linus would not
> "pull" from URLs and such?
I'm all for it. I think it's a good thing.
In the absence of significant latency issues, pull scales better than push.
It always has. Push is better in low bandwidth situations with lots of idle
capacity, but it breaks down when the system approaches saturation.
Pull data is naturally supplied when you're ready for it (assuming no
significant latency to access it). Push either scrolls by unread or piles up
in your inbox and gets buried until it goes stale. Web pages work on a pull
model, "push" was an internet fad a few years ago that failed for a reason.
When push models hit saturation it breaks down and you wind up with the old
"I love lucy" episode with the chocolate factory. Back in the days where
ethernet used hubs instead of switches, going over 50% utilization could lock
the whole network pretty easily, and these days with switched gigabit
eithernet you still have network interfaces going into interrupt livelock but
able to handle a higher load in polling mode. The Linux scheduler itself
pulls tasks from a pool of runnable tasks. If each task had a timer that
expired generating an interrupt that pushed it to a processor, things
wouldn't work so well. (I could go on...)
Linus has actually been using his mailbox to simulate pull by keeping the
push model at saturation and having repeated retransmits of stuff he expects
to repeatedly delete until he's ready to reach out and grab it as it passes
by when the time is right. The flood he's plucking stuff from is his inbox
instead of the internet, but the fact remains 90% of it flows by unread
(wasting attention to delete it, a small amount but it adds up), and isn't
guaranteed to be there when he IS ready for it.
Humans naturally work by pull. It just works better to grab stuff out of the
fridge when you're hungry instead of having it crammed down your throat at
random. Push winds up going into a buffer which we pull from (which is how
mail works), and if that buffer overflows during load spikes, or is just
constantly filling faster than it drains in the long term, then you wind up
retransmitting stuff that got dropped (increasing the bandwidth usage) and it
all just falls apart...
Years ago, Linus wasn't regularly at saturation, so push was fine. (Optimal
even: interrupts are better than polling up until you approach livelock.)
And with Linus's previous toolset, grabbing code from URLs was a significant
interruption in his workflow, hence a bad thing. But with bitkeeper, it
isn't. And if Linus is going to focus on taking the bulk of new patches from
a dozen or so trusted lieutenants anyway, it makes sense for them to give him
the option of a pull model.
I'd encourage this trend. If in the future linus pulls from lieutenants and
lieutenants pull from maintainers, the dropped patches problem basically goes
away. Just make sure that when the level above you IS ready to take it from
your level, it's there and ready for them...
Rob
Standard disclaimer: it's 4:30am, who knows how much sense this will make in
the morning? :)
-
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/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:26 EST