Hi all. Greg, yes the page pool is virtually addressable by the kernel, but as you said, the page boundaries are an issue. I am in fact exploring this route right now, but Jukka's suggestion is also a valid topic to discuss, what I'm doing does not exclude what Jukka and Zyfeier are proposing.
In order to get cross page access I need to implement a dynamic vma area for the kernel. This requires a bit of infrastructure but I already have most of it up and running. What I have now is a mechanism to obtain the kernel addressable pointer for the semaphore and this really does fix the semaphore issue. But as you mentioned, the page boundaries are a problem, and getting that to work is not trivial, but doable. This "dynamic kernel mapping"-API is generally useful e.g. for I/O remap, so I will implement it regardless. However I would still like to discuss the option to split the semaphore structure, as it avoids doing a page directory walk every time the semaphore is accessed. Btw, the semaphore memory must be mapped when calling sem_wait(), because tcb->waitobj is used by the scheduler and using dynamic mappings or put/get_user() (because they are what they say, the COPY data, not refer to it) for that will just simply destroy the scheduling performance. I also thought that mqueue:s would need a similar fix but I think I'm wrong on that one, the mqueue memory is kernel memory and the user accesses it via a file descriptor handle only. Br, Ville Juven / pussuw on github On Mon, Apr 17, 2023 at 6:50 PM Gregory Nutt <spudan...@gmail.com> wrote: > Linux uses functions like copytouser() and copyfromuser() to get > information to/from user space. > > 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. > > 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 > >> > >
