Hi, thanks for your contribution to the discussion! Gregory Nutt kirjoitti maanantai 17. huhtikuuta 2023: > Linux uses functions like copytouser() and copyfromuser() to get > information to/from user space. >
I'm afraid that using this for semaphores would become quite heavy... > But I think there is an easier way in NuttX. All user memory comes from > a poll of pages that are also mapped in kernel space. I think that is > true for all architectures. And there should be a function to convert a > user virtual address to a user virtual address to physical address. I > am not sure what all is in place. > > Couldn't accessing user memory from the kernel address alias avoid the > problem you describe. Of course, you would have to be careful at page > boundaries because contiguous virtual pages may not be physically > contiguous. Yes, this is exactly the workaround which we have used. And as you stated, it breaks when the needed structure happens to be on the page boundary. Another way around would be mapping the pages for kernel. This is not complex, but still requires finding free virtual memory area for the purpose. And, mapping two full pages for just one semaphore. So it is not so nice. > > On 4/14/2023 6:18 AM, Jukka Laitinen wrote: > > Hi, > > > > I am not sure whether it is necessary to separate mutex and semaphore > > (although I do see the performance gain that it would give for mutex), > > but there is another related topic I would like to raise. > > > > Currently, the semaphores don't work (at all) for CONFIG_BUILD_KERNEL. > > The simple reason is that the semaphores are allocated from the > > user-mapped memory, which is not always available for the kernel while > > scheduling or in interrupts. At the time when it is needed, there may > > be another memory map active for mmu. > > > > There is also an issue with performance; every semaphore access needs > > to go to the kernel through syscall, although in principle the > > semaphore counter handling alone doesn't need that if the compiler & > > hw has the necessary atomic support. > > > > We are especially interested in having real-time behaviour (priority > > based scheduling, priority inheritance...) AND running > > CONFIG_BUILD_KERNEL. We have used some methods to circumvent the > > issue, but for those I am not going into details as we don't have a > > publishable implementation ready. > > > > A tempting way to fix the problem (which we didn't try out yet) would > > be separating the semaphores in two parts, kernel side structure and > > the user side structure. Something that zyfeier also did with the > > "futex" linux-like implementation. But, also this kind of > > implementation should be real-time - so when there is access to the > > semaphore via syscall (e.g. when the semaphore blocks), or when > > scheduling, the kernel must have O(1) access to the kernel side > > structure - no hashing / allocating etc. at runtime. > > > > So to summarize, for CONFIG_BUILD_KERNEL the semaphores could > > *perhaps* work like this (this is not yet tried out, so please forgive > > me if something is forgotten): > > - User-side semaphore handle would have the counter and a direct > > pointer (handle) to the kernel side structure (which can be passed to > > kernel in syscall). > > - Kernel side structure would have the needed wait queue and sem > > holder structures (and flags?) > > - Kernel side structure would be allocated at sem_init (AND if it was > > not initialized, allocate it at the time when it is needed?). To > > achieve real-time behaviour one should just call sem_init properly at > > startup of the application. > > - Kernel side structures would be listed in tcb and cleaned up at > > task_group exit. Also some hard limit/management for how much kernel > > memory can one process eat from kernel heap is needed. > > - Counter manipulation can be handled directly in libc in case > > compiler supports proper atomic operations, or syscall to kernel when > > there is no support available (this would be just performance > > optimization - next phase) > > > > Whether it is feasible to do it only for CONFIG_BUILD_KERNEL, or as a > > common implementation for all build modes, I didn't think of yet. I > > am also not sure whether the re-design of semaphore could also lead to > > better wrapping of it for mutex use, but this is also possible. In > > that case it could *maybe* solve the performance issue zyfeier tried > > to tackle. > > > > This is just one idea, but somehow the problem of not working > > semaphores in CONFIG_BUILD_KERNEL should be tackled. I wonder if this > > is something we should experiment with? If someone is interested in > > such an experiment, please let me know. Or if someone is interested in > > doing this experiment, please let me know as well, so we don't end up > > doing duplicate work :) > > > > Br, > > Jukka > > > > Ps. I think that in the current implementation the nxmutex code is > > inlined everywhere, increasing code size. Not a huge issue for me, but > > increasing code size should be managed.... > > > > On 7.4.2023 5.18, zyfeier wrote: > >> > >> Thank you very much for the example you provided. What I want to > >> point out is that this is not just about " just delete / replace what > >> is already out there working fine ". Due to the multi-holder of the > >> count semaphore, the performance of the mutex is much worse than > >> other RTOS (with a performance gap of 10%), but these operations are > >> not necessary for the mutex. That's why there is an idea to separate > >> the mutex and semaphore. > >> > >> However, if everyone thinks that separating the mutex and semaphore > >> is a bad idea, then we need to think of other methods. Do you have > >> any better methods to offer? > >> > >> 从Windows 版邮件 <https://go.microsoft.com/fwlink/?LinkId=550986>发送 > >> > >> *发件人: *Tomek CEDRO <mailto:to...@cedro.info> > >> *发送时间: *2023年4月6日22:36 > >> *收件人: *dev@nuttx.apache.org > >> *主题: *Re: [Breaking change] Move nxmutex to sched > >> > >> On Thu, Apr 6, 2023 at 2:58 PM Gregory Nutt wrote: > >> > Oh my God! That sounds terrible! Does this change actually do > >> > /anything /positive. > >> > >> Look Zyfeier, its not that we oppose development, we want the > >> development to done the right way that will bring elegant coherent > >> standard compliant solution as a result :-) > >> > >> Aside from my previous remark on Linux (along with other commercial > >> OS) "enforced changes", lets think about Greg's "does this change > >> actually do /anything /positive" question with another example. > >> > >> Take a looks at WS2812 RGB Smart LED. They decided to introduce "an > >> innovation" by changing the Pin1 marking on the casing and put that > >> mark on pin 3 instead. Whole world use Pin1 marking to quickly align > >> a component pinout, so at first glance you can see where is the pin 1 > >> of the component, also most chips use VCC there so you can quickly > >> measure things, nothing fancy, everyone knows that. Now take a look > >> at the pcb design footprint (bottom layer mirrored) and the led > >> datasheet. > >> > >> > >> You can clearly see that putting Pin1 casing mark on pin 3 is a > >> terrible idea, even more that chip is symmetrical, so it will lead to > >> bad placing and reversed power supply. Sure, this is some innovation, > >> but world does not work that way and everyone just gets confused. > >> When you make such changes to other components a design becomes > >> incoherent and no one will then know anything, but look how many > >> (fake) "innovations" just showed up. > >> > >> This is why solid coherent standardized fundamentals / foundations of > >> technology is so important. So we "just know" things intuitively, and > >> we can work together to improve things worldwide in a systematic > >> fashion, solid brick after solid brick, evolution not revolution. You > >> cannot just delete / replace what is already out there working fine. > >> > >> Example above is about electronic component, but with the software is > >> exactly the same, it is good to stick to well adapted standards, add > >> your own brick on top of solid inviolable fundamentals / fundation, > >> not necessarily following the quickly changing fashions and trends > >> with a lifespan of a yogurt, not spreading bad habits from other > >> environments, that will result in far better solution that is > >> coherent and long term maintainable. That results in a solid > >> foundation for a good system / device / solution / product. > >> > >> > >> -- > >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > >> > >
