It's arguable. When I went there a few months back, I was a little
surprised by the way it adds ram+swap (it mistakenly added in more
before) to make that decision; but concluded it was helping callers
who might well go on to add ram+swap, and felt no overriding reason
to change that. But you can certainly argue that's inappropriate
for the kernel to do, that it should only guard the validity of
the actual numbers it returns to the caller. No strong feelings.
> The appended patch implements that (and makes the logic a little bit
> easier)
Alan, please don't apply. The patch made the logic a lot easier,
but sadly wrong: try what happens to totalswap 0x00120000 with
mem_unit 0x1000 - wrong decision since 0x20000000 > 0x00120000.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/