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
> 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
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
> 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.