On Mon, Jul 15, 2013 at 04:25:54PM -0400, Prarit Bhargava wrote: > > 1.1M isn't small. We recently declined to build btrfs into the kernel > > because it increased the overall memory usage by a similar amount. > > Also, we regularly see users and bug reports still in the 2G range. > > OOC what was the objection to 1M? Is there some lower limit I should be > concerned about? Too bad we don't have smolts running any more, it would be useful to see the minimum RAM we're running on these days. We used to squeeze by in 512MB though that was with a basic desktop, none of the shiny stuff we have now. It's not just a memory footprint thing. Enabling CPU counts that large forces cpumasks off the stack as I'm sure you know, so the average Fedora user would have to pay the performance penalty of that, for enabling something that realistically, isn't going to common-place for some time. (Though for some reason, we have CONFIG_OFFSTACK enabled everywhere right now, which seems like an oversight) > > While it's not an apples to apples comparison, far more Fedora users > > are going to be using btrfs than > 128 CPUs. I'm not saying no > > immediately, but I'm kinda dubious as to the benefits for Fedora. > > We're already exceeding 128 cpus on a regular basis (or at least I am). Getting > testing in the upper range only improves Fedora ... IMO. I think we can safely say you're an outlier though. I don't recall seeing Fedora bug reports of >32 CPUs on x86-64. (I'm struggling to recall any past 8-16 tbh). We periodically bump it up a power of 2 every so often as end-user hardware moves, and I don't recall a time when we've had users having to ask us to bump it. We're currently at 128 on x86-64, which is about 120 more than the average end-user tends to have. Dave _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
