linux-kernel - Re: [PATCH 407/493] infiniband: remove use of _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 Nov 2012 15:48:45 -0700
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Bill Pemberton <wfp5p@...ginia.edu>, linux-kernel@...r.kernel.org,
	linux-rdma@...r.kernel.org
Subject: Re: [PATCH 407/493] infiniband: remove use of __devexit

On Mon, Nov 19, 2012 at 02:06:32PM -0800, Greg KH wrote:

> > 5k isn't a lot, but in the context of 'I have to figure out how to
> > trim ~1MB off the 3.6 kernel to run it in our smallest hardware' it is
> > the wrong direction :(
> 
> It is only 0.138% in the "wrong" direction.  Seriously, that's a very
> tiny percentage here, for an option that people _always_ get wrong, and
> almost no system does not need.  The number of bugs we have had in this
> area is huge, and by fixing this option like this, it takes them all
> away.

Sure, it isn't a lot. I don't have any idea about problems
CONFIG_HOTPLUG causes, but it seems alot of work has gone into making
this option over the years (the patch to remove it is huge), is there
no other way to get what you want?

> Yes, there are going to be exceptions, like yours, that somehow do run
> properly without CONFIG_HOTPLUG enabled.  But really, are you worried
> about 0.138% right now?  The amount of time we just spent writing these
> emails, memory sizes increased this much for your next platform, for the
> same cost as your last platform.

Well, I'm not worried looking forward, as you say, it just doesn't
matter. The systems we designed today have 128M and that was pretty
much the *smallest* dram we could provision.

> Thanks for running the numbers, I appreciate it.  I'm amazed that your
> kernel growth from 2.6.16 to 3.6 is 1Mb.  Why would you want to run the
> 3.6 kernel in a system designed for the 2.6.16 kernel (i.e. one designed
> over 6 _years_ ago)?

I haven't had any time to inspect the 1MB growth, so I can't comment
on what is going on there.. A chunk of that will be some initrd
growth too..

As for why the interest in upgrading? Well, we don't make consumer
products, our stuff has long life cycles and the 6 year old system
continues to be manufactured and sold today.

Our latest platform is ARM based, and we've had to re-spin and re-test
*everything*. The work to bundle PPC along in that effort is fairly
minor, so we are looking at keeping it up-to-date with our unified
firmware.

Regards,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/