[CentOS-devel] CentOS Cloud SIG?

[Johnny Hughes]

On 01/13/2014 12:41 PM, Josh Boyer wrote:
> On Sat, Jan 11, 2014 at 5:51 PM, Karanbir Singh <mail-lists at karan.org> wrote:
>> On 01/10/2014 12:32 PM, Josh Boyer wrote:
>>> On Thu, Jan 9, 2014 at 5:28 PM, Karanbir Singh <mail-lists at karan.org> wrote:
>>>> On 01/09/2014 02:22 PM, Josh Boyer wrote:
>>>>> OK, but it's still a kernel based on the RHEL kernel, just with the
>>>>> changes/additions backported to it.  It isn't a bump to e.g. the Linux
>>>>> 3.10 stable release or something.  Correct?
>>>> the xen4centos kernel is mainline based 3.x
>>> Interesting.  I'll have a look.  Do you know or have pointers to why
>>> they chose to go that route?
>>>
>> We tried, quite a bit, to try and get the xen stuff backported into the
>> 2.6.32-EL6 kernel, but given the patch overlap was something we cant
>> control and lack the time and technical depth in kernel code to maintain
>> that longer term ( this was essentially Johnny and me, doing this over
>> and above most other things ), it was just easier to go down that route.
> OK.  Those kinds of reasons are what I would expect to drive a
> divergence from the disto kernel.  I'm curious to see how those kinds
> of situations work out in terms of bug reports and additional
> maintenance burden.
>
>> Secondly, there are quite a few anecdotal pieces on dramatic performance
>> improvements in newer kernels, I know atleast one of the top 5 CDN's (
>> ie carry > 25Gibt/sec ) that recently switched over from the distro
>> centos kernel to a inhouse 3.10 build for 'network perforamnce'.
>>
>> In quotes, because repeated questions and pokes in various media have
>> failed to get a reasonable, tangiable, technical response out of them
>> beyond 'network perforamance'.
> Interesting.  I suppose it's possible but without actually data
> there's really no way to tell.  It might even be that they modified
> 3.10 themselves to gain that performance and are reluctant to talk
> about it?
>
> Thanks for the info.  I'll keep watching the lists for SIG proposals
> with interest.

Well, in the case of the Xen kernel, we needed things already rolled
into the 3.x tree for Xen4 that we could not backport those with our
current skill set.  We also wanted something that lasts a long time and
gets updates, so we settled on the LTS kernels.

We currently have 3.10.x and no kabi support.  That means kmods are a
PITA, but we were able to roll in the newest upstream (from xen) blktap
modules into both the kernel and our Xen RPMS.

We can likely use this kernel in other SIGs, hopefully as is or as a
group modify it so it works for the Xen SIG and the other SIGs too.  The
goal is maintaining one Kernel, not several.  The point of doing the LTS
one is that kernel.org is rolling back both new hardware support and
security updates for a couple of years on the LTS kernels.
 
Thanks,
Johnny Hughes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140114/a52b94a0/attachment.sig>