Re: [osv-dev] Lazily allocating thread stacks WIP

On Sunday, January 12, 2020 at 9:32:36 AM UTC-6, Waldek Kozaczuk wrote: > > Hi Matthew, > > Have you made any progress on it? > I got stuck on tst-vfs.so and was unable to find out what was causing the illegal access. > Nadav, > If you have a bit of time would you mind giving your feedback on

Re: [osv-dev] Lazily allocating thread stacks WIP

Hi Matthew, Have you made any progress on it? Nadav, If you have a bit of time would you mind giving your feedback on what we are proposing/discussing here? I put some sort of summary of it in the comments of the issue - https://github.com/cloudius-systems/osv/issues/143#issuecomment-567232417

Re: [osv-dev] Lazily allocating thread stacks WIP

On Friday, December 13, 2019 at 5:26:46 PM UTC-5, Waldek Kozaczuk wrote: > > Some other thoughts: > > 1. All the increments and decrements of the *stack_page_read_counter* > should be symmetrical. Decrementing it in wait_for_interrupts() does not > seem to but if I remember correctly when I was

Re: [osv-dev] Lazily allocating thread stacks WIP

Some other thoughts: 1. All the increments and decrements of the *stack_page_read_counter* should be symmetrical. Decrementing it in wait_for_interrupts() does not seem to but if I remember correctly when I was trying to get it all to work I had to put it there, maybe because we start with 1. B

Re: [osv-dev] Lazily allocating thread stacks WIP

Great stuff Waldek! That solved a few of the issues I was running into. However, tst-vfs.so is still failing occasionally with the error I mentioned earlier (std::length_error), which apparently is usually the result of an illegal memory access, probably caused by the changes to thread::init_st

Re: [osv-dev] Lazily allocating thread stacks WIP

It was pretty late when I was sending this email. So to recap more clearly how this patch works: 1. The stack_page_read_counter is a thread-local variable initialized to 1 and behaves similarly to the preempt_counter 2. For every new thread (except the very first one) its thread_main_c (see htt

Re: [osv-dev] Lazily allocating thread stacks WIP

So here is a new very roughy patch that handles the problem of nested calls to disable interrupts and/or preemption: diff --git a/arch/x64/arch-switch.hh b/arch/x64/arch-switch.hh index 6803498f..70224472 100644 --- a/arch/x64/arch-switch.hh +++ b/arch/x64/arch-switch.hh @@ -148,6 +148,11 @@ void

Re: [osv-dev] Lazily allocating thread stacks WIP

So I think the thread::prepare_wait() is called in this context which indeed disables preemption: 1080 void thread::prepare_wait() 1081 { 1082 // After setting the thread's status to "waiting", we must not preempt it, 1083 // as it is no longer in "running" state and therefore will not

Re: [osv-dev] Lazily allocating thread stacks WIP

So I have applied your patch (had to manually reformat it from the email so it might be somewhat different): diff --git a/arch/x64/arch-switch.hh b/arch/x64/arch-switch.hh index 6803498f..70224472 100644 --- a/arch/x64/arch-switch.hh +++ b/arch/x64/arch-switch.hh @@ -148,6 +148,11 @@ void thread:

Re: [osv-dev] Lazily allocating thread stacks WIP

Hi, On Tuesday, December 10, 2019 at 1:26:31 PM UTC-5, Matthew Pabst wrote: > > On Sunday, December 8, 2019 at 1:03:45 PM UTC-6, Waldek Kozaczuk wrote: >> >> >> I think it is more than just "wasting the last page of a small stack". >> Without a check to validate if we are reading within the bound

Re: [osv-dev] Lazily allocating thread stacks WIP

On Sunday, December 8, 2019 at 1:03:45 PM UTC-6, Waldek Kozaczuk wrote: > > > I think it is more than just "wasting the last page of a small stack". > Without a check to validate if we are reading within the bounds of the > stack, we could cause unintended faults that would actually crash the app

Re: [osv-dev] Lazily allocating thread stacks WIP

On Sunday, December 8, 2019 at 12:58:35 PM UTC-5, Nadav Har'El wrote: > > On Sun, Dec 8, 2019 at 4:10 PM Waldek Kozaczuk > wrote: > >> >> >> On Sun, Dec 8, 2019 at 07:32 Nadav Har'El > > wrote: >> >>> >>> On Sat, Dec 7, 2019 at 6:07 AM Waldek Kozaczuk >> > wrote: >>> On second thought, let

Re: [osv-dev] Lazily allocating thread stacks WIP

On Sun, Dec 8, 2019 at 4:10 PM Waldek Kozaczuk wrote: > > > On Sun, Dec 8, 2019 at 07:32 Nadav Har'El wrote: > >> >> On Sat, Dec 7, 2019 at 6:07 AM Waldek Kozaczuk >> wrote: >> >>> On second thought, let me tweak my suggestions and add some more. >>> >>> On Friday, December 6, 2019 at 5:05:03 P

Re: [osv-dev] Lazily allocating thread stacks WIP

On Sun, Dec 8, 2019 at 07:32 Nadav Har'El wrote: > > On Sat, Dec 7, 2019 at 6:07 AM Waldek Kozaczuk > wrote: > >> On second thought, let me tweak my suggestions and add some more. >> >> On Friday, December 6, 2019 at 5:05:03 PM UTC-5, Waldek Kozaczuk wrote: >>> >>> >>> >>> On Friday, December 6,

Re: [osv-dev] Lazily allocating thread stacks WIP

On Sat, Dec 7, 2019 at 6:07 AM Waldek Kozaczuk wrote: > On second thought, let me tweak my suggestions and add some more. > > On Friday, December 6, 2019 at 5:05:03 PM UTC-5, Waldek Kozaczuk wrote: >> >> >> >> On Friday, December 6, 2019 at 4:06:07 PM UTC-5, Matthew Pabst wrote: >>> >>> Ah, I thi

Re: [osv-dev] Lazily allocating thread stacks WIP

On second thought, let me tweak my suggestions and add some more. On Friday, December 6, 2019 at 5:05:03 PM UTC-5, Waldek Kozaczuk wrote: > > > > On Friday, December 6, 2019 at 4:06:07 PM UTC-5, Matthew Pabst wrote: >> >> Ah, I think I understand things better now. >> >> Here is my current idea fo

Re: [osv-dev] Lazily allocating thread stacks WIP

On Friday, December 6, 2019 at 4:06:07 PM UTC-5, Matthew Pabst wrote: > > Ah, I think I understand things better now. > > Here is my current idea for a solution: > > Everytime we disable interrupts and preemption (in irq_disable() and > preempt_disable()), we call a method like ensure_stack_mapp

Re: [osv-dev] Lazily allocating thread stacks WIP

Ah, I think I understand things better now. Here is my current idea for a solution: Everytime we disable interrupts and preemption (in irq_disable() and preempt_disable()), we call a method like ensure_stack_mapped(), which will do the following: - If the current stack pointer is in a regio

Re: [osv-dev] Lazily allocating thread stacks WIP

On Tue, Dec 3, 2019 at 5:56 PM Matthew Pabst wrote: > Thanks for the response. > > I've been trying to think through the logic for this change more, and I'm > don't completely understand the proposed solution. > > For example, say the program faults on a stack page. Then before disabling > interr

Re: [osv-dev] Lazily allocating thread stacks WIP

Nadav would be the best authority to answer it. But I think that all exception handlers including page fault use its own exception stack (see https://github.com/cloudius-systems/osv/blob/3357ae0798fc3abece7a068d0b48cea050281852/arch/x64/arch-switch.hh#L86) which is 4 pages long. So we should b

Re: [osv-dev] Lazily allocating thread stacks WIP

Thanks for the response. I've been trying to think through the logic for this change more, and I'm don't completely understand the proposed solution. For example, say the program faults on a stack page. Then before disabling interrupts we access the next stack page(s). If one of those pages is

Re: [osv-dev] Lazily allocating thread stacks WIP

On Tue, Dec 3, 2019 at 9:09 AM Matthew Pabst wrote: > I've been working on this issue > for the past couple > days, and I have a couple questions as well as a WIP solution. > > I figured I would start by implementing a simple solution that acce

[osv-dev] Lazily allocating thread stacks WIP

I've been working on this issue for the past couple days, and I have a couple questions as well as a WIP solution. I figured I would start by implementing a simple solution that accesses the next stack page in preempt_disable() and irq_disabl