bug-parallel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cannot specify the number of threads for parsort


From: Ole Tange
Subject: Re: Cannot specify the number of threads for parsort
Date: Thu, 16 Feb 2023 09:28:21 +0100

On Sat, Feb 11, 2023 at 3:18 AM Sam James <sam@cmpct.info> wrote:
> > On 11 Feb 2023, at 01:44, Mario Roy <marioeroy@gmail.com> wrote:
> >
> > > Can you explain why you need this? To me it seems odd not to use all the 
> > > cores you paid for.
> >
:
> > No, not at all. Having the -j option to parsort is desirable on larger 
> > NUMA-aware machines. This is true when a node is busy and wish to run on 
> > the other node. [...]
> >
> Yeah, it's pretty normal to want to limit the number of jobs either because 
> of other work one is doing on the machine, or because others are using the 
> machine.

There is probably something I am missing, but why not simply use
'nice'? If you are on a shared system and want to give others
priority, using 'nice' seems to me like the obvious choice: No CPU
will sit idle, and those who need priority will get it.

Can you elaborate on what I am missing from the picture?

For my work I made 'reniced' which would renice jobs that had run for
a certain amount of CPU time. This way people could run interactive
short jobs with high priority, but if they started long running jobs
they would have to nice it themselves or have 'reniced' come do it
later.

https://gitlab.com/ole.tange/tangetools/-/tree/master/reniced

/Ole



reply via email to

[Prev in Thread] Current Thread [Next in Thread]