gmane.linux.redhat.fedora.kernel

Re: CONFIG_NR_CPUS

Josh Boyer — 2012-05-24T11:34:17

We made the change 2 days ago.  You're belaboring the point just a bit
now.

Also, the cheapest of these is $13k.  That's roughly 10x the cost of a
mid-high end home desktop and well outside Fedora's normal target user.
If someone wants to spend that kind of money on an enterprise server and
run Fedora on it, I'll gladly thank them for being a user but most of
those kinds of purchases are done by businesses that want something a
bit more stable and supported.


Hello ARM?

josh
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Xose Vazquez Perez — 2012-05-23T23:35:59


Also 
http://www.fujitsu.com/fts/products/computing/servers/primergy/rack/rx900/

... and more are coming.

Good bye Itanium, SPARC and POWER.
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Xose Vazquez Perez — 2012-05-23T23:21:36


bigger *Xeon* server, 8_sockets * 10_cores * 2_threads = 160

Sun Fire X4800 M2 Server:
http://www.oracle.com/us/products/servers-storage/servers/x86/sun-fire-x4800-m2/overview/index.html

Super Micro X8OBN-F:
http://www.supermicro.com/products/motherboard/Xeon7000/7500/x8obn-f.cfm

2x HP ProLiant DL980 G7 Server (HP PREMA):
http://h10010.www1.hp.com/wwpc/us/en/sm/WF04a/15351-15351-3328412-241644-4222584.html?dnr=1

2x IBM System x3950 X5 (2-node):
http://www-03.ibm.com/systems/x/hardware/enterprise/x3850x5/index.html

SGI servers need MAXSMP.
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

3.5 merge started

Josh Boyer — 2012-05-22T14:53:47

Mostly as FYI, I've started building the 3.5 merge window kernels today.
The one building in Koji right now boots on my local x86_64 system
without issue.  I'm not sure if that trend will continue, but I plan on
testing locally before I do koji builds.

I've done the first round of Kconfig options settings.  Secondary
architectures, please review this and let me know if you want/need
something set differently from how I have it.

NOTE: The ARM configs are both confusing and too numerous, so I have not
touched those.  Also, the kernel-3.5.0-arm.config file seems to be dummy
and winds up with a lot of options unset.  The ARM team will need to do
some config option settings, preferrably sooner rather than later.
Perhaps as time goes on, I'll gain a better understanding of what to set
where and how.

josh
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: What is the earliest x86 64bit CPU we support?

Justin M. Forbes — 2012-05-21T17:16:34

I still have one of the original Opteron boards here, it is supported
fine (though heats the room).  AFAIK there aren't any true x86_64 CPUs
that we don't support.

Justin

_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: What is the earliest x86 64bit CPU we support?

Dave Jones — 2012-05-21T14:50:46

 > So... what is it?
 > 
 > I think the earliest is the AMD Opteron (2003).
 > 
 > From a "earliest in each family" perspective, I think the answer is:
 > 
 > AMD: AMD Opteron (2003).
 > Intel: Intel Xeon (Nocona) (2004)
 > VIA: VIA Nano (2008)
 > 
 > Excluding Itanium (thank god), are there any other early x86 64bit CPUs
 > that I'm missing or any that we explicitly no longer support?

Not that I recall. We should support any x86-64 machine.
If there's one we don't work on, it's likely a bug.

Dave
 
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

What is the earliest x86 64bit CPU we support?

Tom Callaway — 2012-05-21T14:41:39

So... what is it?

I think the earliest is the AMD Opteron (2003).

From a "earliest in each family" perspective, I think the answer is:

AMD: AMD Opteron (2003).
Intel: Intel Xeon (Nocona) (2004)
VIA: VIA Nano (2008)

Excluding Itanium (thank god), are there any other early x86 64bit CPUs
that I'm missing or any that we explicitly no longer support?

~tom

==
Fedora Project
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Prarit Bhargava — 2012-05-21T13:25:38


I'd like to see 32-bit go away :)  Please? :) :) :)

Seriously though, I think giving people yet another excuse to migrate away from
32-bit is a good idea and I cannot see any merit in increasing the 32-bit NR_CPUS.

P.
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Josh Boyer — 2012-05-21T13:13:48

I'll get this into rawhide shortly unless someone else brings up
counter-points (doubtful).


I'm not concerned with the stability aspect of it.  Before the
recent-ish change, we had it set to 256 on released kernels and 512 for
rawhide/debug kernels.  We know it works.  For rawhide/debug kernels we
already set it to MAXSMP.

For the record, I'm not going to change 32-bit kernels.  I don't see
much of a need to increase that beyond what it is today and the same
arguments about more cores being added don't really apply to 32-bit
chips.

(Before someone points out that you can run 32-bit kernels on 64-bit
hardware, I just wanted to say I don't care.  If you have a CPU that has
128 cores and want to use them all, use a 64-bit kernel ;) .)

josh
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Prarit Bhargava — 2012-05-21T12:42:12

Xose,

We should start supporting these in Fedora.  These are not unusual to find in
systems.

Josh, the reality is that 64 isn't "enough" anymore.  Even deskside systems are
starting to ship with 32 cores, so increasing the number of CPUs to 128 is a
good idea.  I've had a lot of experience with larger systems.  The increase in
memory footprint is minimal (a few Kb, not Mb).

I do know that some vendors who do upstream development, do install Fedora on
systems with greater than 64 logical cpus.  It would be good if we could support
them fully.

Jumping to 128 is a very good idea.  We know it is stable given RHEL's support
of 4096 (again, I don't think Fedora should entertain jumping to 4096 for a
variety of reasons).

In short, ACK ;)

P.

_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Prarit Bhargava — 2012-05-21T12:32:37

This is from RHEL which has a markedly different user base than Fedora does.  I
remember setting this in RHEL based on a partner request who ships LARGE systems
(4096 CPUs, many many many TB of memory).

This is not the number you want for Fedora.


I think we did that in RHEL.  It is insignificant IIRC.  I'll try and dig out
some numbers...

P.
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Gilboa Davara — 2012-05-21T07:30:35

On Mon, May 21, 2012 at 1:25 AM, Xose Vazquez Perez
<xose.vazquez< at >gmail.com> wrote:

Keep in mind that this bug is ~5 y/o.
The last 5 years seen an explosion in both core count and standard
memory size in servers.
(While on the other hand, a lot of progress was made to reduce the
static allocations tied to NR_CPUS)

- Gilboa
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Ruben Kerkhof — 2012-05-21T00:09:32

On Mon, May 21, 2012 at 12:25 AM, Xose Vazquez Perez
<xose.vazquez< at >gmail.com> wrote:

That's on an ancient kernel. I believe some work has been done to
reduce the overhead of cpu masks, see
https://lkml.org/lkml/2012/2/15/546 for example.

Regards,

Ruben
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Xose Vazquez Perez — 2012-05-20T22:25:41


https://bugzilla.redhat.com/show_bug.cgi?id=219457
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Xose Vazquez Perez — 2012-05-20T22:20:13


- Xeon E7:
http://en.wikipedia.org/wiki/Nehalem_%28microarchitecture%29#Server_.2F_Desktop_Processors_2

http://www-03.ibm.com/systems/x/hardware/enterprise/x3850x5/index.html
http://h10010.www1.hp.com/wwpc/us/en/sm/WF04a/15351-15351-3328412-241644-4222584.html?dnr=1
http://www.dell.com/us/business/p/poweredge-r910/pd

- Opteron 6200:
http://en.wikipedia.org/wiki/List_of_AMD_Opteron_microprocessors#Opteron_6200-series_.22Interlagos.22_.2832_nm.29

http://www-03.ibm.com/systems/x/hardware/rack/x3755m3/index.html
http://h10010.www1.hp.com/wwpc/us/en/sm/WF04a/15351-15351-3328412-241644-3328422.html?dnr=1
http://www.dell.com/us/business/p/poweredge-r815/pd
http://www.supermicro.nl/Aplus/motherboard/Opteron6000/SR56x0/H8QG6-F.cfm

[.....]

secondary archs:
z196: 24sockets * 4cores = 96, but only 80IFL.
power7: 32sockets * 8cores * 4 threads = 1024, 795 and 775 servers.
sparc: we will see, when oracle release Oracle Enterprise Linux for SPARC.
_______________________________________________
kernel mailing list
k

Re: CONFIG_NR_CPUS

Ruben Kerkhof — 2012-05-20T15:23:04

It's even higher these days:

grep NR_CPUS /boot/config-2.6.32-220.13.1.el6.x86_64
CONFIG_NR_CPUS=4096

I'm curious, has anyone measured what the memory overhead is of
keeping NR_CPUS at 512?
arch/x86/Kconfig says "This is purely to save memory - each supported
CPU adds approximately eight kilobytes to the kernel image." If that's
true, 512 cpus use 4MB, something I'm willing to live with on my 64bit
 servers.

Thanks,

Ruben
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Gilboa Davara — 2012-05-20T12:32:39

At least in my case I did run Fedora 12-16 on 4S and 8S machines to
test software scalability on (extreme) high-end hardware.
Though, IMHO anyone that's crazy enough to run Fedora on a high-end
4S/8S machine is more than capable of rebuilding the kernel with
CONFIG_NR_CPUS 256...

However, given the fact that x86_64 machines tend to be far less
memory constrained than i686 machines, I doubt that raising the limit
to 128 will cause too many issues. (Isn't NR_CPUS == 512 in el6?)

- Gilboa
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: CONFIG_NR_CPUS

Josh Boyer — 2012-05-20T01:07:40

Awesome.  Got that covered still.


Which particular CPU/Motherboard combo is that, and how often do we see
it in Fedora?

I'm not opposed to bumping it up to 128 or something, but I'm curious
how many people are actually going to see benefits.

josh
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

CONFIG_NR_CPUS

Xose Vazquez Perez — 2012-05-19T12:54:33


_today_

amd:   4sockets * 16cores = 64
intel: 4sockets * 10cores * 2threads = 80
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

mount --move

Norman Gaywood — 2012-05-17T23:51:31

I'm pretty sure that in 3.3.2-6.fc16.x86_64 this sequence worked:

  mkdir -p /tmp/testing
  cd /tmp/testing/
  mkdir -p foo bar
  mount -t tmpfs tmpfs foo/
  mount --move foo bar/

With 3.3.5-2.fc16.x86_64 the last step gives:

mount: wrong fs type, bad option, bad superblock on /tmp/testing/foo,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Didn't test any kernels between those two.

Is this a bug or feature? Didn't see anything is syslog.

Re: Experimental kernels with inode-uprobes, without utrace

Anton Arapov — 2012-05-16T12:55:43

Hello All,

  I've built kernels with uprobes patches for Fedora 17 and Rawhide. All
backported uprobes patches are in -tip:perf/uprobe tree and aimed for
linux-3.5 merge.
  Git tree: http://j.mp/JDu8sM
  Fedora Yum repo: http://j.mp/LN8vZO
  How to try uprobes using perf or sysfs: http://j.mp/LN9fhi http://j.mp/KwKzs4

cheers,
Anton Arapov.
twitter.com/aarapov

On Wed, Nov 16, 2011 at 03:45:16PM +0100, Anton Arapov wrote:
_______________________________________________
kernel mailing list
kernel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel