5 ms·

Choosing between programming in the kernel or in user space

65 points by jsnell 9y ago

cjbprime 9y ago
Answer seems like a bad take to me. There are plenty of zero-copy userspace APIs, if memory copies are even a bottleneck.
- jeff571 9y ago
  Yeah exactly! Just look at DPDK for example.
deleted 9y ago
[deleted]
jacksmith21006 9y ago
Be interesting to include Meltdown as a factor in the discussion at this point from a performance standpoint.
tptacek 9y ago
This answer is malpractice on at least two levels: 1. It entertains a performance argument without interrogating the task and environment the appliance is engaged in. You can always in theory make a typical program faster by rewriting it in carefully scheduled assembly. We don't often do that because the performance win would be irrelevant to the problems we're trying to solve. 2. It pretends that the only reliability benefit from moving to u from k is in virtual memory. But, no: the major benefit is from moving from C to something more expressive and safer. The notion of "defect density" captures this argument: with it held constant, a solution that can be expressed in fewer lines of code will have fewer faults. But, of course, defect density between C and a high-level language won't be constant, and it won't favor C, where you can't even count safely with the basic types provided by the language.
- koverstreet 9y ago
  Malpractice? Strong words, considering you're mischaracterizing the article. "Virtual memory—which gives us the user/kernel space split and the process model of programming whereby programs are protected from each other—is just the most pervasive form of isolation." That's not claiming virtual memory is the only reliability benefit, and you can't expect a short article to be a treatise on all the differences between kernel space and userspace. Furthermore, the article isn't claiming that kernel programming is _better_ than userspace programming, it's just pointing out that there's a tension between performance and safety - which you acknowledge!
  - tptacek 9y ago
    There isn't necessarily even that tension. Modern high-speed networking does TCP/IP entirely in userspace.
    - koverstreet 9y ago
      When networking is faster in userspace it's because it's a clean slate implementation, not because userspace is faster.
      - JoachimSchipper 9y ago
        A TCP/IP stack isn't fundamentally faster for running in user- or kernelspace, but avoiding user/kernel transitions helps. So maximum-performance implementations that don't need to care about playing nice with others might be best off choosing one or the other and staying there; running in userland is then more convenient (but e.g. the TUX in-kernel webserver exists/existed.) Mind you, most high-performance software doesn't need to go this far, and stuff like PF_RING / Linux' packet_mmap or "batched" systems calls like recvmmsg() (or even read()) further reduces the number userland/kernel transitions.
        koverstreet 9y ago
        The vast majority of the time though you need to let multiple processes use the same TCP/IP stack. As soon as you have to do that, moving the TCP/IP stack to userspace means you have to do context switches instead of syscalls. That is not a good thing if you care about performance.
- codemac 9y ago
  Once the driver doesn't exist in the kernel (vfio/iommu), and you have processes and threads and efence/mprotect, this all doesn't make sense for practical purposes. The author's reasoning just doesn't hold up in modern networking and storage appliances when it comes to state of the art performance in Linux userspace.
- aidenn0 9y ago
  RE: 2 There is no reason HLLs can't be used in kernel space, is there? Excepting shell-like languages (which require fork, which you typically can't do in a kernel), most embedded kernels provide everything a HLL might expect in kernelspace.
andyidsinga 9y ago
THIS : " If your problem must be decomposed into a set of cooperating processes, then programming in user space is the exact same problem as programming in the kernel" Corollary (in my experience): many systems evolve to have many cooperating processes. and THIS: "The tension in any of these systems is between performance and isolation." To solve for the root issue described - hiring(1) - they should be looking for people who have an aptitudes for these those types of issues ..more so than say kernel or user space skills & experience. (1) "HR complained that they could not find sufficient, qualified engineers to meet the demands of management for more hands to make more features"
- TheAceOfHearts 9y ago
  Minor unrelated complaint, but when you write "hiring(1)" like that, it immediately makes me think there's an unknown man page I need to read rather than a footnote reference. In my experience, citations and footnotes generally use brackets, e.g. "hiring[1]".
maga_2020 9y ago
The succinctly noted "The tension in any of these systems is between performance and isolation. " Also caught my attention. In my mind it is a bit analogues to discussion about 'microservices'. Although micro services, are probably at the peak of the Hype Cycle. Where isolation is projected as 'productivity enabler', across teams. Very difficult to challenge this, especially if you work for a company where revenue is declining/not growing because of lack of ideation/innovation/market conditions. So, when company fails to ideate and grow revenue, the product management/CIO will be turning onto the productivity. I suspect the next move for the company, where the above is discussed, -- is moving Development to a lower cost area. Especially if the 'hiring problem HR is noting' is not just with requirements, but also salary ceilings.

65 points by jsnell 9y ago

Answer seems like a bad take to me. There are plenty of zero-copy userspace APIs, if memory copies are even a bottleneck.

jeff571 9y ago
Yeah exactly! Just look at DPDK for example.

deleted 9y ago

[deleted]

jacksmith21006 9y ago

Be interesting to include Meltdown as a factor in the discussion at this point from a performance standpoint.

tptacek 9y ago

This answer is malpractice on at least two levels: 1. It entertains a performance argument without interrogating the task and environment the appliance is engaged in. You can always in theory make a typical program faster by rewriting it in carefully scheduled assembly. We don't often do that because the performance win would be irrelevant to the problems we're trying to solve. 2. It pretends that the only reliability benefit from moving to u from k is in virtual memory. But, no: the major benefit is from moving from C to something more expressive and safer. The notion of "defect density" captures this argument: with it held constant, a solution that can be expressed in fewer lines of code will have fewer faults. But, of course, defect density between C and a high-level language won't be constant, and it won't favor C, where you can't even count safely with the basic types provided by the language.

koverstreet 9y ago
Malpractice? Strong words, considering you're mischaracterizing the article. "Virtual memory—which gives us the user/kernel space split and the process model of programming whereby programs are protected from each other—is just the most pervasive form of isolation." That's not claiming virtual memory is the only reliability benefit, and you can't expect a short article to be a treatise on all the differences between kernel space and userspace. Furthermore, the article isn't claiming that kernel programming is _better_ than userspace programming, it's just pointing out that there's a tension between performance and safety - which you acknowledge!
- tptacek 9y ago
  There isn't necessarily even that tension. Modern high-speed networking does TCP/IP entirely in userspace.
  - koverstreet 9y ago
    When networking is faster in userspace it's because it's a clean slate implementation, not because userspace is faster.
    - JoachimSchipper 9y ago
      A TCP/IP stack isn't fundamentally faster for running in user- or kernelspace, but avoiding user/kernel transitions helps. So maximum-performance implementations that don't need to care about playing nice with others might be best off choosing one or the other and staying there; running in userland is then more convenient (but e.g. the TUX in-kernel webserver exists/existed.) Mind you, most high-performance software doesn't need to go this far, and stuff like PF_RING / Linux' packet_mmap or "batched" systems calls like recvmmsg() (or even read()) further reduces the number userland/kernel transitions.
      - koverstreet 9y ago
        The vast majority of the time though you need to let multiple processes use the same TCP/IP stack. As soon as you have to do that, moving the TCP/IP stack to userspace means you have to do context switches instead of syscalls. That is not a good thing if you care about performance.
codemac 9y ago
Once the driver doesn't exist in the kernel (vfio/iommu), and you have processes and threads and efence/mprotect, this all doesn't make sense for practical purposes. The author's reasoning just doesn't hold up in modern networking and storage appliances when it comes to state of the art performance in Linux userspace.
aidenn0 9y ago
RE: 2 There is no reason HLLs can't be used in kernel space, is there? Excepting shell-like languages (which require fork, which you typically can't do in a kernel), most embedded kernels provide everything a HLL might expect in kernelspace.

andyidsinga 9y ago

THIS : " If your problem must be decomposed into a set of cooperating processes, then programming in user space is the exact same problem as programming in the kernel" Corollary (in my experience): many systems evolve to have many cooperating processes. and THIS: "The tension in any of these systems is between performance and isolation." To solve for the root issue described - hiring(1) - they should be looking for people who have an aptitudes for these those types of issues ..more so than say kernel or user space skills & experience. (1) "HR complained that they could not find sufficient, qualified engineers to meet the demands of management for more hands to make more features"

TheAceOfHearts 9y ago
Minor unrelated complaint, but when you write "hiring(1)" like that, it immediately makes me think there's an unknown man page I need to read rather than a footnote reference. In my experience, citations and footnotes generally use brackets, e.g. "hiring[1]".

maga_2020 9y ago

The succinctly noted "The tension in any of these systems is between performance and isolation. " Also caught my attention. In my mind it is a bit analogues to discussion about 'microservices'. Although micro services, are probably at the peak of the Hype Cycle. Where isolation is projected as 'productivity enabler', across teams. Very difficult to challenge this, especially if you work for a company where revenue is declining/not growing because of lack of ideation/innovation/market conditions. So, when company fails to ideate and grow revenue, the product management/CIO will be turning onto the productivity. I suspect the next move for the company, where the above is discussed, -- is moving Development to a lower cost area. Especially if the 'hiring problem HR is noting' is not just with requirements, but also salary ceilings.