Also, you can configure the kernel at boot to exclude certain cpus from the OS
completely so no process can interfere with them - BUT - processes/threads can
still be moved to these isolated cpus using setsched().
> On Sep 27, 2024, at 10:34 AM, robert engels wrote:
>
> What you want to do is
What you want to do is start the process with a cset to restrict the cores it
can use - then use the setsched to move certain threads to cores that have been
excluded.
> On Sep 27, 2024, at 10:26 AM, 'TheDiveO' via golang-nuts
> wrote:
>
> Are you running this on a multi-core? Your non-fifo t
You can add as a benefit to your module that it avoids the *supply chain
nightmare* that thereceipe/qt is (as you describe the latter: "It works by
making IPC calls to a separate C++ binary downloaded at runtime from a site
under the maintainer's control. This may be less performant than calling
Seems to have changed, as there have been quite some more kthread-types
sprung up. Oh, you're reminding me ask the OP a question just to be sure...
On Friday, September 27, 2024 at 5:53:33 PM UTC+2 robert engels wrote:
> I am not sure that is true unless things have changed. You can configure
>
just to be sure: you *do* actually use an RT kernel? I know you can set ff
on stock non-RT kernels, but the results can be quite different.
On Thursday, September 26, 2024 at 5:49:53 AM UTC+2 Zhao Weng wrote:
> Hi gophers,
> I'm doing a research on how to prioritise some goroutines over others.
I am not sure that is true unless things have changed. You can configure the
interrupt/kernel handlers to run on specific cpus and keep other cpus and their
caches completely isolated. There was an issue at one point with clock timings
but as I recall it was resolved (it’s been several years so
you need to keep a bunch of per-cpu ("per-core") kernel threads and you
need to make sure not to starve them, but for a short test that's okay. oh,
and don't have any processes running that use io uring...
On Friday, September 27, 2024 at 5:37:53 PM UTC+2 robert engels wrote:
> Also, you can co
Are you running this on a multi-core? Your non-fifo tasks can be scheduled
to other cores, et cetera. BTW, fifo 99 is a recipe for desaster as it can
starve the kernel on a core, preventing necessary kernel house-keeping.
Don't ask me how I know...
What is the reason for setting GOMAXPROCS, I'm
Maybe I should apologize for the origin of this idea:
https://github.com/go101/go101/wiki/How-to-perfectly-clone-a-slice%3F
When I posted that wiki article, I was not aware of this (maybe tiny)
drawback.
My current opinion is that it is best to let the Go runtime specialize
zero-capacity slic
