Well, if we are talking about deleting the startup task I dont see how that is much different than malloc; I might be missing something though. If we are talking about designating a startup task and that stack always stays with that task, I get that… of course, you hope that the task normally requires a large stack or you are just wasting memory.
Admittedly I am not terribly keen about malloc or adjusting idle task stack, etc, etc. Given how it seems mynewt is going, I would probably agree that a fair amount of mallocing is not done in “task context”. In other projects I have worked on, quite a bit of the mallocs were done by a task so not having all the heap available to start would not really be an issue (and I am not concerned about heap fragmentation in this regard as, to me, it really only is an issue of not having all the heap available when most things are malloc’d). Anyway, I obviously dont have a great solution nor do I have a strong preference for any of the aforementioned approaches :-) > On Dec 12, 2016, at 8:23 AM, marko kiiskila <[email protected]> wrote: > > >> On Dec 11, 2016, at 11:21 AM, Sterling Hughes <[email protected]> wrote: >> >> Hi, >> >>> >>>> On Dec 11, 2016, at 10:55 AM, Christopher Collins <[email protected]> >>>> wrote: >>>> >>>> On Sun, Dec 11, 2016 at 10:11:44AM -0800, will sanfilippo wrote: >>>>> Personally, I keep wanting to try and have the OS start up right away. >>>> >>>> I wonder if this could solve the problem that Sterling raised (no >>>> default event queue during sysinit). The control flow in main() might >>>> look like this: >>>> >>>> 1. Start OS >>>> 2. Create and designate default event queue. >>>> 3. sysinit() >>>> >>>> I think it would be nice if we could avoid adding another initialization >>>> stage. >>>> >> >> +1 > > I agree. If there are too many options here, it becomes even harder to > understand. Preferably we should keep this stuff simple, making the barrier of > entry to development lower. > >> >>>>> There are definitely “issues” with this: >>>>> a) We do not want to waste idle task stack. >>>>> b) When tasks are started they would start running right away. This >>>>> might cause issues where a task does something to a piece of memory >>>>> that another task initializes, but since that other task has not >>>>> initialized it yet… >>>>> >>>>> b) can be avoided by locking the scheduler until initializations are >>>>> finished. >>>>> >>>>> a) is problematic :-) I think someone brought this up before, but I >>>>> wonder if it is worth the effort to do something “a bit crazy” like >>>>> the following: the idle task uses “the heap” during intialization. >>>>> Once initializations are over (or at some point that we determine), >>>>> the idle task stack is made smaller and the “top” of the heap is set >>>>> to the end of the idle task stack. For example, idle task stack is at >>>>> 0x20008000 and is of size 1K bytes; the bottom of the heap is at >>>>> 0x20007000; the top of the heap is at 0x20007C00 (in my nomenclature, >>>>> heap allocations start from the bottom). At some point, the top of the >>>>> heap is moved to 0x20007F80. >>>>> >>>>> Yeah, maybe a bit crazy… :-) >>>> >>>> I don't think that's too crazy. It would be great if we could just >>>> malloc() a temporary stack, and then free it when initialization >>>> completes. I guess the worry is that this will cause heap >>>> fragmentation? >>>> >> >> I’m not crazy about malloc()’ing this space. Especially since system init >> (where we’d use this memory) is where people malloc() their memory pools, >> and so you have 1K of space that could potentially affect memory exhaustion. >> Maybe its an awful idea… but why not let people specify the startup task >> stack, and we can guarantee that this task gets deleted before the rest of >> the tasks/system runs. That way, you can just choose one of your task’s >> stacks that is sufficiently large, and use that for startup stack. >> > > Most of the malloc()’s for packages happen when they’re initialized. > And having malloc()’d init stack present during this step will have effect > on this. And freeing the stack right after will automatically lead to heap > fragmentation. > And we’d need some new, mandatory, architecture specific code which > switches stacks for a task while the task is running. While not complex, > it is yet another thing to write/debug when adding a new architecture. > > However, I like the idea of app assigning a startup task, and then executing > sysinit() in that task’s context. >
