[GitHub] [incubator-nuttx] v01d opened a new issue #3355: TOO MANY SYSCALLS

[GitBox <gi...@apache.org>]

v01d opened a new issue #3355:
URL: https://github.com/apache/incubator-nuttx/issues/3355


   ```
     Description: There are a few syscalls that operate very often in user space.
                  Since syscalls are (relatively) time consuming this could be
                  a performance issue.  Here is some numbers that I collected
                  in an application that was doing mostly printf output:
   
                    sem_post - 18% of syscalls
                    sem_wait - 18% of syscalls
                    getpid   - 59% of syscalls
                    --------------------------
                               95% of syscalls
   
                  Obviously system performance could be improved greatly by simply
                  optimizing these functions so that they do not need to system calls
                  so frequently.  This getpid() call is part of the re-entrant
                  semaphore logic used with printf() and other C buffered I/O.
                  Something like TLS might be used to retain the thread's ID
                  locally.
   
                  Linux, for example, has functions call up() and down().  up()
                  increments the semaphore count but does not call into the kernel
                  unless incrementing the count unblocks a task; similarly, down
                  decrements the count and does not call into the kernel unless
                  the count becomes negative the caller must be blocked.
   
                  Update:
                  "I am thinking that there should be a "magic" global, user-
                   accessible variable that holds the PID of the currently
                   executing thread; basically the PID of the task at the head
                   of the ready-to-run list. This variable would have to be reset
                   each time the head of the ready-to-run list changes.
   
                  "Then getpid() could be implemented in user space with no system call
                   by simply reading this variable.
   
                  "This one would be easy: Just a change to include/nuttx/userspace.h,
                   boards/<arch>/<chip>/<board>/kernel/up_userspace.c, libs/libc/,
                   sched/sched_addreadytorun.c, and sched/sched_removereadytorun.c.
                   That would eliminate 59% of the syscalls."
   
                  Update:
                  This is probably also just a symptom of the OS test that does mostly
                  console output.  The requests for the pid() are part of the
                  implementation of the I/O's re-entrant semaphore implementation and
                  would not be an issue in the more general case.
   
                  Update:
                  One solution might be to use TLS, add the PID to struct
                  tls_info_s.  Then the PID could be obtained without a system call.
                  TLS is not very useful in the FLAT build, however.  TLS works by
                  putting per-thread data at the bottom of an aligned stack.  The
                  current stack pointer is then ANDed with the alignment mask to
                  obtain the per-thread data address.
   
                  There are problems with this in the FLAT and PROTECTED builds:
                  First the maximum size of the stack is limited by the number
                  of bits in the mask.  This means that you need to have a very
                  high alignment to support tasks with large stacks.  But
                  secondly, the higher the alignment of the stacks stacks, the
                  more memory is lost to fragmentation.
   
                  In the KERNEL build, the the stack lies at a virtual address
                  and it is possible to have highly aligned stacks with no such
                  penalties.
     Status:      Open
     Priority:    Low-Medium.  Right now, I do not know if these syscalls are a
                  real performance issue or not.  The above statistics were collected
                  from a an atypical application (the OS test), and does an excessive
                  amount of console output.  There is probably no issue with more typical
                  embedded applications.
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org