Celelibi
2016-Jan-27 01:46 UTC
[syslinux] [PATCH 2/2] core: Fix stack overflow when reloading config
2016-01-26 20:22 UTC+01:00, H. Peter Anvin <hpa at zytor.com>:> On 01/26/16 06:55, Celelibi wrote: >> >> Do you mean executables should also stay in memory and just get a >> fast-reinitialization when re-running them? >> > > Yes. I hope that it would make things a lot faster, especially over the > network. However, it wouldn't really matter in the common case of just > showing a menu and booting from there; now when we have hierarchical menus. > >> However, unless we do something more heavy-weight, when a config file >> is loaded, I guess all modules will have to be unloaded anyway since >> the search path can be changed by the new config file and other >> modules with the same name can be loaded. > > Hm. We could rather easily deal with that by storing the full path of > the module; that way we can distinguish them. >That means modules will accumulate in memory. If we add a way to prune the least recently used modules when memory is required, that become quite close to the file system cache I had in mind with the solution 3. ^^ Except it's specialized for modules.>> BTW, can ldlinux.c32 be affected by the PATH directive or another >> configuration option? > > Not at the moment, and I don't think it should be. ldlinux.c32 is very > closely coupled with the bootstrap part of the bootloader itself.Thanks, that's what I thought. Celelibi
H. Peter Anvin
2016-Jan-27 02:06 UTC
[syslinux] [PATCH 2/2] core: Fix stack overflow when reloading config
On January 26, 2016 5:46:25 PM PST, Celelibi <celelibi at gmail.com> wrote:>2016-01-26 20:22 UTC+01:00, H. Peter Anvin <hpa at zytor.com>: >> On 01/26/16 06:55, Celelibi wrote: >>> >>> Do you mean executables should also stay in memory and just get a >>> fast-reinitialization when re-running them? >>> >> >> Yes. I hope that it would make things a lot faster, especially over >the >> network. However, it wouldn't really matter in the common case of >just >> showing a menu and booting from there; now when we have hierarchical >menus. >> >>> However, unless we do something more heavy-weight, when a config >file >>> is loaded, I guess all modules will have to be unloaded anyway since >>> the search path can be changed by the new config file and other >>> modules with the same name can be loaded. >> >> Hm. We could rather easily deal with that by storing the full path >of >> the module; that way we can distinguish them. >> > >That means modules will accumulate in memory. If we add a way to prune >the least recently used modules when memory is required, that become >quite close to the file system cache I had in mind with the solution >3. ^^ Except it's specialized for modules. > > >>> BTW, can ldlinux.c32 be affected by the PATH directive or another >>> configuration option? >> >> Not at the moment, and I don't think it should be. ldlinux.c32 is >very >> closely coupled with the bootstrap part of the bootloader itself. > >Thanks, that's what I thought. > > >CelelibiYes, we could expire them, and that probably would make sense once we cross a certain memory threshold. The big question is if that would ever actually happen. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
Celelibi
2016-Feb-03 15:15 UTC
[syslinux] [PATCH 2/2] core: Fix stack overflow when reloading config
2016-01-27 3:06 UTC+01:00, H. Peter Anvin <hpa at zytor.com>:> On January 26, 2016 5:46:25 PM PST, Celelibi <celelibi at gmail.com> wrote: >>2016-01-26 20:22 UTC+01:00, H. Peter Anvin <hpa at zytor.com>: >>> On 01/26/16 06:55, Celelibi wrote: >>>> >>>> Do you mean executables should also stay in memory and just get a >>>> fast-reinitialization when re-running them? >>>> >>> >>> Yes. I hope that it would make things a lot faster, especially over >>the >>> network. However, it wouldn't really matter in the common case of >>just >>> showing a menu and booting from there; now when we have hierarchical >>menus. >>> >>>> However, unless we do something more heavy-weight, when a config >>file >>>> is loaded, I guess all modules will have to be unloaded anyway since >>>> the search path can be changed by the new config file and other >>>> modules with the same name can be loaded. >>> >>> Hm. We could rather easily deal with that by storing the full path >>of >>> the module; that way we can distinguish them. >>> >> >>That means modules will accumulate in memory. If we add a way to prune >>the least recently used modules when memory is required, that become >>quite close to the file system cache I had in mind with the solution >>3. ^^ Except it's specialized for modules. >> >> >>>> BTW, can ldlinux.c32 be affected by the PATH directive or another >>>> configuration option? >>> >>> Not at the moment, and I don't think it should be. ldlinux.c32 is >>very >>> closely coupled with the bootstrap part of the bootloader itself. >> >>Thanks, that's what I thought. >> >> >>Celelibi > > Yes, we could expire them, and that probably would make sense once we cross > a certain memory threshold. The big question is if that would ever actually > happen.I'm not really comfortable about making the assumption that we have a lot of memory available. I'm far from knowing all the use cases of syslinux. Celelibi
Seemingly Similar Threads
- [PATCH 2/2] core: Fix stack overflow when reloading config
- [PATCH 2/2] core: Fix stack overflow when reloading config
- [PATCH 2/2] core: Fix stack overflow when reloading config
- [PATCH 2/2] core: Fix stack overflow when reloading config
- [PATCH 2/2] core: Fix stack overflow when reloading config