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