Evolution of kernel size

Evolution of kernel size

[Jérôme Pinot]

Hi,

I took some time to make a graph of the evolution of the size of the
linux kernel tar.bz2 since version 1.0 till 3.1 (297 releases).
It doesn't count the stable branches (2.6.x.y).

Impressive, it's mostly exponential.
If dev keeps same pace, we should break the 100MB at
linux 3.19.

You can get the graph on my blog, I provide the data and the
gnuplot batch file for graphing/fitting:
http://ngc891.blogdns.net/?p=92 

It may interest some people :-)

-- 
Jérôme Pinot
http://ngc891.blogdns.net/

Re: Evolution of kernel size

[Nick Bowler]

On 2011-11-10 23:33 +0900, Jérôme Pinot wrote:
> I took some time to make a graph of the evolution of the size of the
> linux kernel tar.bz2 since version 1.0 till 3.1 (297 releases).
> It doesn't count the stable branches (2.6.x.y).
> 
> Impressive, it's mostly exponential.
> If dev keeps same pace, we should break the 100MB at
> linux 3.19.
> 
> You can get the graph on my blog, I provide the data and the
> gnuplot batch file for graphing/fitting:
> http://ngc891.blogdns.net/?p=92 
> 
> It may interest some people :-)

What scale did you use for the horizontal axis?  I see numbers assigned
to each version in your gnuplot file, but no indication of how you came
up with them.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Evolution of kernel size

[Jérôme Pinot]

On 11/10/11 09:59, Nick Bowler wrote:
> On 2011-11-10 23:33 +0900, Jérôme Pinot wrote:
> > I took some time to make a graph of the evolution of the size of the
> > linux kernel tar.bz2 since version 1.0 till 3.1 (297 releases).
> > It doesn't count the stable branches (2.6.x.y).
> > 
> > Impressive, it's mostly exponential.
> > If dev keeps same pace, we should break the 100MB at
> > linux 3.19.
> > 
> > You can get the graph on my blog, I provide the data and the
> > gnuplot batch file for graphing/fitting:
> > http://ngc891.blogdns.net/?p=92 
> > 
> > It may interest some people :-)
> 
> What scale did you use for the horizontal axis?  I see numbers assigned
> to each version in your gnuplot file, but no indication of how you came
> up with them.

It's just the release count, one step for one release.

Some release are missing, mostly at the very beginning, I didn't find
tarball for them but it doesn't matter much for the shape of the curve.

-- 
Jérôme Pinot
http://ngc891.blogdns.net/

Re: Evolution of kernel size

[Nick Bowler]

On 2011-11-11 00:15 +0900, Jérôme Pinot wrote:
> On 11/10/11 09:59, Nick Bowler wrote:
> > On 2011-11-10 23:33 +0900, Jérôme Pinot wrote:
> > > I took some time to make a graph of the evolution of the size of the
> > > linux kernel tar.bz2 since version 1.0 till 3.1 (297 releases).
> > > It doesn't count the stable branches (2.6.x.y).
> > > 
> > > Impressive, it's mostly exponential.
> > > If dev keeps same pace, we should break the 100MB at
> > > linux 3.19.
> > > 
> > > You can get the graph on my blog, I provide the data and the
> > > gnuplot batch file for graphing/fitting:
> > > http://ngc891.blogdns.net/?p=92 
> > > 
> > > It may interest some people :-)
> > 
> > What scale did you use for the horizontal axis?  I see numbers assigned
> > to each version in your gnuplot file, but no indication of how you came
> > up with them.
> 
> It's just the release count, one step for one release.
> 
> Some release are missing, mostly at the very beginning, I didn't find
> tarball for them but it doesn't matter much for the shape of the curve.

The problem with this is that the releases were not made at fixed
intervals.  2.6.0 -> 3.0 represents more than double the amount of
development time as 2.4 -> 2.6, yet they get roughly the same amount
of horizontal space on your plot.

I think it would be much more interesting to scale by release dates, so
that the gap between releases is proportional to the time between them.
I suspect you'll see a very different shape.

Furthermore, looking at the raw data, you gave 2.4.37 (released in 2008)
a lower release number than 2.6.0 (released in 2003), which seems odd.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Evolution of kernel size

[Jérôme Pinot]

On 11/10/11 10:40, Nick Bowler wrote:
> On 2011-11-11 00:15 +0900, Jérôme Pinot wrote:
> > On 11/10/11 09:59, Nick Bowler wrote:
> > > On 2011-11-10 23:33 +0900, Jérôme Pinot wrote:
> > > > I took some time to make a graph of the evolution of the size of the
> > > > linux kernel tar.bz2 since version 1.0 till 3.1 (297 releases).
> > > > It doesn't count the stable branches (2.6.x.y).
> > > > 
> > > > Impressive, it's mostly exponential.
> > > > If dev keeps same pace, we should break the 100MB at
> > > > linux 3.19.
> > > > 
> > > > You can get the graph on my blog, I provide the data and the
> > > > gnuplot batch file for graphing/fitting:
> > > > http://ngc891.blogdns.net/?p=92 
> > > > 
> > > > It may interest some people :-)
> > > 
> > > What scale did you use for the horizontal axis?  I see numbers assigned
> > > to each version in your gnuplot file, but no indication of how you came
> > > up with them.
> > 
> > It's just the release count, one step for one release.
> > 
> > Some release are missing, mostly at the very beginning, I didn't find
> > tarball for them but it doesn't matter much for the shape of the curve.
> 
> The problem with this is that the releases were not made at fixed
> intervals.  2.6.0 -> 3.0 represents more than double the amount of
> development time as 2.4 -> 2.6, yet they get roughly the same amount
> of horizontal space on your plot.

It's because my point was not about studying size(time) but
size(version).

> I think it would be much more interesting to scale by release dates, so
> that the gap between releases is proportional to the time between them.
> I suspect you'll see a very different shape.

It's another point of view which is interesting too.

> Furthermore, looking at the raw data, you gave 2.4.37 (released in 2008)
> a lower release number than 2.6.0 (released in 2003), which seems odd.

Well, branches evolve in parallel, like the 2.4/2.6 move, so you can't
fit these in one unique time-based graph (or it's a mess).
Moreover, code was backported from 2.6 to 2.4 (remember the xfs
thing?), so the 2.4.37 kernel is actually the one from 2.4 branch
to be the more like 2.6.0. It's not a huge nonsense to put the
two releases side by side to compare the code size.

If you like a time-based graph, you'd better to have a graph for each
branch. That's an other work.

-- 
Jérôme Pinot
http://ngc891.blogdns.net/

Re: Evolution of kernel size

[Ted Ts'o]

On Thu, Nov 10, 2011 at 11:33:33PM +0900, Jérôme Pinot wrote:
> Hi,
> 
> I took some time to make a graph of the evolution of the size of the
> linux kernel tar.bz2 since version 1.0 till 3.1 (297 releases).
> It doesn't count the stable branches (2.6.x.y).

The question really is what are you trying to show with the graph, and
what do you plan to use the graph for?  If it is estimating the size
of disk space that you'll need at some point in the future, that's
fine.  If it's for entertainment value, that's fine too.

But if it's to try to make some claims about (for example) kernel
complexity, you'd do better to measure the size of various specific
subsystems, such as mm, core kernel, a specific file system, etc.  And
even then, the statistics can be misleading since sometimes
refactoring to reduce complexity or removing unneeded abstraction
layers can end up reducing the size of the subsystem, but leave it in
a more maintainable state.

						- Ted

Re: Evolution of kernel size

[Jérôme Pinot]

On 11/11/11 11:51, Ted Ts'o wrote:
> On Thu, Nov 10, 2011 at 11:33:33PM +0900, Jérôme Pinot wrote:
> > Hi,
> > 
> > I took some time to make a graph of the evolution of the size of the
> > linux kernel tar.bz2 since version 1.0 till 3.1 (297 releases).
> > It doesn't count the stable branches (2.6.x.y).
> 
> The question really is what are you trying to show with the graph, and
> what do you plan to use the graph for?  If it is estimating the size
> of disk space that you'll need at some point in the future, that's
> fine.  If it's for entertainment value, that's fine too.

That's exactly the point :-)

> But if it's to try to make some claims about (for example) kernel
> complexity, you'd do better to measure the size of various specific
> subsystems, such as mm, core kernel, a specific file system, etc.  And
> even then, the statistics can be misleading since sometimes
> refactoring to reduce complexity or removing unneeded abstraction
> layers can end up reducing the size of the subsystem, but leave it in
> a more maintainable state.

Measuring code complexity or work/cost of the source code was out of my
scope.

-- 
Jérôme Pinot
http://ngc891.blogdns.net/