Am 02.05.2013 16:32, schrieb Aaron Durbin:
I am wondering why the ramstage stack size is so large on a lot of boards:
Is this just an artifact of copy-n-paste? What is driving the requirement for such large stack sizes?
Other than for wakeup-from-suspend, no-one ever cares if that's 4k or 400k, except that things might fail if it is too small.
And Google is the first organisation with a huge interest in an optimized wakeup in coreboot.
Patrick
On Thu, May 2, 2013 at 10:40 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Am 02.05.2013 16:32, schrieb Aaron Durbin:
I am wondering why the ramstage stack size is so large on a lot of boards:
Is this just an artifact of copy-n-paste? What is driving the requirement for such large stack sizes?
Other than for wakeup-from-suspend, no-one ever cares if that's 4k or 400k, except that things might fail if it is too small.
Presumably the stack poisoning has somewhat of an impact on boot times and coreboot users generally care about that? 64KiB stack with MAX_CPUS = 16 is 1MiB of memory just for stack and it's poisoning. It's definitely not dire, but just something to think about. I'm not sure what the expectations are for boot time from existing users.
-Aaron
* Patrick Georgi patrick@georgi-clan.de [130502 17:40]:
Am 02.05.2013 16:32, schrieb Aaron Durbin:
I am wondering why the ramstage stack size is so large on a lot of boards:
Is this just an artifact of copy-n-paste? What is driving the requirement for such large stack sizes?
Other than for wakeup-from-suspend, no-one ever cares if that's 4k or 400k, except that things might fail if it is too small.
And Google is the first organisation with a huge interest in an optimized wakeup in coreboot.
Patrick
It is true. As soon as coreboot has suspend/resume enabled, the memory used by coreboot is permanently lost to the OS. While nobody cares about 400K missing on a 4G system, it would still be nice to only use what we need; Otherwise people could start thinking coreboot is a big and clunky firmware framework rather than a sleek and slim solution.
Stefan