|
>> The current implementation of my original 2.2.x patch in the 2.6.x
>> kernel is in my view unfinished and can hardly be used in production for
>> sites with heaps of page views and business logics in application servers.
>>
>> Threshold limitation patch and user space patch follow.
>>
>> Please discuss,
>
> Conceptually it seems like a reasonable idea, though if
> you have per-real server thresholds is it really needed?
No and yes. The hprio scheduler is not needed anymore for the spillover
(or session overflow) pool implementation, since the switch from native
RS to spillover happens atomically in the kernel. Since I did not have
this code until 2 weeks ago, the hprio scheduler kind of replaced that
functionality, at least using a RR scheduler.
It could be needed though if you want stacked addition of RS to handle
spike loads for you system. So long as everything is working normally
the spare servers can be used for other things.
> In terms of code, it looks good, though traversing the
> real-serves in ip_vs_hprio_max_weight() and again in
> ip_vs_hprio_schedule() seems like it could be merged
> into a single loop. But thats not a big deal.
Indeed it could. Even better would be to put the max_weight into
ip_vs_ctl.c where the interaction with user space is happening since
it's the only place where weights get changed and max weight is a pretty
static thing.
> I'm not sure if its really material to to go upstream.
That's ok. So long as the rest can be merged, once I get the 2.6 port
ready.
> If you think it is, then a 2.6 version will be the way to
> go as I believe 2.4 is only accepting bug fixes now.
Unfortunately yes. I'll certainly cook up a 2.6 version of my patch.
This will also allow me to get a broader test base and acceptance by the
users.
Thanks Horms,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
