CpuSet Feature While Using Upmpdcli

[ekpln]

Hi,

I enabled cpuset package and 'm pusing mconnect app with upmpdcli, everything is perfect.

Yesterday, I controlled CPU usage and allocations, and I saw that Upmpdcli was working on CPU1 (user), but MPD was working on CPU0 (system).
As far as I know, music player(mpd) should play on CPU1 for best sound. I want to isolate upmpd and mpd on CPU1 from every other thing that is working on CPU 0.

As you can see, PID numbers:
MPD: 1197,
Upmpdcli: 1181

 

You can see that Upmpdcli is working on CPU1, while MPD is working on CPU0.



So, What can I do for isolating MPD on CPU1 with Upmpdcli on startup? I have some Linux skills then I'm open for all suggestions

Thank you,

[agent_kith]

Hmm.. Can you try and run:

Code:

sudo cset proc --move --pid=PID --threads --toset=user --force

Replace PID (e.g. 1197) with the current PID, and let me know how it goes.

That's the current workaround for now while I work on why it didn't move it before. I suspect this is a race condition (MPD didn't start quick enough), or I only moved the server app, but not the client app!

Have created a ticket, and I'll sort it out in the next release.

[Snoopy8]

Hmm.. Can you try and run:

Code:

sudo cset proc --move --pid=PID --threads --toset=user --force

Replace PID (e.g. 1197) with the current PID, and let me know how it goes.

That's the current workaround for now while I work on why it didn't move it before. I suspect this is a race condition (MPD didn't start quick enough), or I only moved the server app, but not the client app!

Have created a ticket, and I'll sort it out in the next release.

Adding my scenario of using MinimServer with upmpdcli. 

I have 4 cores, cores 0 & 1 allocated for system,  cores 2 & 3 for music player.  Mpd is using Core 1.  Upmpdcli is using Core 2.  Minimserver (running Java) is using Core 0.  Is MinimServer considered part of system or player?

[ekpln]

Hmm.. Can you try and run:

Code:

sudo cset proc --move --pid=PID --threads --toset=user --force

Replace PID (e.g. 1197) with the current PID, and let me know how it goes.

That's the current workaround for now while I work on why it didn't move it before. I suspect this is a race condition (MPD didn't start quick enough), or I only moved the server app, but not the client app!

Have created a ticket, and I'll sort it out in the next release.

Yes, it worked! But with each startup, PID of Mpd changes. So I need to otomate the command with updated PID number at startup.

[agent_kith]

This will be fixed in the next update so you don't have to do this manually.

But until then, for a workaroud, you can run something like pgrep to find the PID of MPD.

[Snoopy8]

Also, when running Mpd by itself, on CPU 3 (2 & 3 allocated to player),  Mympd is running in the background using CPU 1 (0 & 1 allocated to system).   Should  Mympd be running in the background?  If so, then should it not be running on a CPU allocated to player?

[PeteCallaghan]

This will be fixed in the next update so you don't have to do this manually.

But until then, for a workaroud, you can run something like pgrep to find the PID of MPD.

I've created a script to set the mpd priority to real time and to move mpd to user:

Create new file mpdpriority.sh with the following lines:

sudo chrt -r -p 99 $(pgrep mpd)
sudo cset proc --move  --threads --toset=user --force --pid=$(pgrep mpd)

You can then run this manually  as sudo sh [path to script file]/mpdpriority.sh

Or set it to run after boot: 

#crontab-e
@reboot root sh [path to script file]/mpdpriority.sh

[agent_kith]

Or set it to run after boot: 

#crontab-e
@reboot root sh [path to script file]/mpdpriority.sh

This will have the same problem with the current setup, as the script could be run before MPD has finished starting up... A workaround is to create a for loop (with sleep to throttle it down), and loop until pgrep returns a PID.

[PeteCallaghan]

Or set it to run after boot: 

#crontab-e
@reboot root sh [path to script file]/mpdpriority.sh

This will have the same problem with the current setup, as the script could be run before MPD has finished starting up... A workaround is to create a for loop (with sleep to throttle it down), and loop until pgrep returns a PID.

You are right - I can't get this to work after reboot, even with this: 
 

Code:

 
while ! pgrep mpd >> /dev/null ;
do
sleep 5
done

---

Or set it to run after boot: 

#crontab-e
@reboot root sh [path to script file]/mpdpriority.sh

This will have the same problem with the current setup, as the script could be run before MPD has finished starting up... A workaround is to create a for loop (with sleep to throttle it down), and loop until pgrep returns a PID.

You are right - I can't get this to work after reboot, even with this: 
 

Code:

 
while ! pgrep mpd >> /dev/null ;
do
sleep 5
done

There seemed to be multiple mpd processes, so a loop was needed to catch them all:
 

Code:

 
pids=$(pgrep mpd)
for pid in $pids
do
chrt -r -p 99 $pid
cset proc --move  --threads --toset=user --force --pid=$pid
done

[agent_kith]

There seemed to be multiple mpd processes, so a loop was needed to catch them all:
 

Code:

 
pids=$(pgrep mpd)
for pid in $pids
do
chrt -r -p 99 $pid
cset proc --move  --threads --toset=user --force --pid=$pid
done

In theory you don't have to do this, just find the main PID, and the --threads option will move all threads to the CPUSet.

But, that's really dependent on how MPD works.. e.g. if MPD fork a thread on playback, there is always a chance this script will not work.. i.e. MPD starts, and the script moves the threads to the CPU Set, and when you play, MPD fork another thread, this is not trapped by the script as it happens after the fact..

There's prob a way to fix this, but I havn't investigate deeply enough yet... The current script, while brutally simple, actually yield quite a good audio improvement.. But I've mostly tested this in LMS and Squeezelite..

Please continue to explore this and let me know your progress, I'll incorporate your work into the next release too.