-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syscall optimize #262
Syscall optimize #262
Conversation
Return from exception is common code for both system calls and exceptions
Also, convert the type to union; we don't need the list element once the item has been popped from the free list (the linkage is never needed when the item is in use).
This patch changes how user service calls are executed: Instead of using the common interrupt logic, execute the user service call directly. Why? When a user makes a service call request, all of the service call parameters are already loaded into the correct registers, thus it makes no sense to first clobber them and then reload them, which is what the old logic does. It is much more effective to run the system call directly. During a user system call the interrupts must be re-enabled, which the new logic does as soon as we know the exception is a user service call request. This patch does NOT change the behavior of reserved system calls (like switch_context), only the user service call request is affected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few minor comments otherwise LGTM, nice improvement
|
||
/* Is it a system call ? */ | ||
|
||
li s3, RISCV_IRQ_ECALLU /* Is it a system call ? */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment already above
@@ -65,16 +65,20 @@ | |||
* will set up [m/s]scratch to point to the CPUs own area | |||
*/ | |||
|
|||
struct riscv_percpu_s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what is going on here, but I find this a bit confusing. Now items of type riscv_percpu_t are list items or not, depending on whether the tcb pointer is used or not....
If you like it like this, the re-use of of riscv_percpu_s type name is confusing, even though it is not(?) used outside this header. Maybe use "union riscv_percpu_u" here instead in that case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently I should have used _u suffix according to the coding standard.
Now items of type riscv_percpu_t are list items or not, depending on whether the tcb pointer is used or no
That is almost the case. riscv_percpu_t are not list items ever, unless they are in the freelist for percpu items. They can never be held as a reference while they are in a list, ever, because the only operation for the list is pop() (and insert() during boot).
Another way to hide this detail would be to split this union into two parts:
- private part, which has the list element and put it into riscv_percpu.c
- public part which is exposed here
I'll not change this now, as this is already in upstream, but I see your point. Maybe I'll clean it up at some point.
System call optimization patches from upstream