Skip to content
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

Many getpid calls wasting CPU resources #5447

Closed
exrok opened this Issue Dec 30, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@exrok
Copy link

exrok commented Dec 30, 2018

With both fish 3.0 and fish 2.7.1 since Glibc disabled the getpid cache, fish shell seems to call getpid a lot. I have observed this issue on Arch linux for a couple of months. Using, the default configuration a strace -c fish followed by a C-d to terminate the shell gives,

time seconds usecs/call calls errors syscall
38.95 0.003541 1 2216 getpid
14.81 0.001346 1 715 13 ioctl
6.59 0.000599 1 353 getpgrp
5.54 0.000504 1 284 fcntl
5.36 0.000487 2 226 79 read

The effect is worse with my current personal configuration, it has even more calls seen below is the top strace results run on fish 3.0.

time seconds usecs/call calls errors syscall
49.25 0.013099 1 8442 getpid
15.75 0.004189 1 2616 255 ioctl

I think many of these calls are probably unnecessary. Further, the shell continues to call a large amount of getpid calls during use as well not just startup.

@faho

This comment has been minimized.

Copy link
Member

faho commented Dec 30, 2018

This is actually mostly down to one single assert.

parser_t &parser_t::principal_parser() {
    ASSERT_IS_NOT_FORKED_CHILD();
    ASSERT_IS_MAIN_THREAD();
    return s_principal_parser;
}

It turns out this is hammered.

Since it's just an assert, let's just remove it.

That reduces my tally from 789 to 15, for a simple fish -ic exit.

Quite surprisingly, it also seems to reduce the time taken for

for i in (seq 10000); test 1 = 1; end

by ~40%.

@faho faho closed this Dec 30, 2018

@faho

This comment has been minimized.

Copy link
Member

faho commented Dec 30, 2018

Fixed by a7998c4.

@faho faho added the enhancement label Dec 30, 2018

@faho faho added this to the fish-3.1 milestone Dec 30, 2018

mqudsi added a commit that referenced this issue Dec 31, 2018

Do not use up the ~WNOHANG waitpid call on completed processes
This is the more correct fix for #5447, as regardless of which process
in the job (be it the first or the last) finished first, once we have
waited on a process without ~WNOHANG we don't do that for any subsequent
processes in the job.

It is also a waste to call into the kernel to wait for a process we
already know is completed!

@faho faho referenced this issue Jan 12, 2019

Closed

fish 3.0.1? #5520

7 of 7 tasks complete

@zanchey zanchey modified the milestones: fish 3.1.0, fish 3.0.1 Jan 18, 2019

@zanchey

This comment has been minimized.

Copy link
Member

zanchey commented Jan 21, 2019

Is a7998c4 safe to go into 3.0.1? I presume ASSERT_IS_NOT_FORKED_CHILD was being called for a reason... I see @mqudsi has optimised this assert significantly but not restored it in this place.

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Jan 21, 2019

Yes it's safe. The assertion is just to catch mistakes, it has no functional purpose.

@floam

This comment has been minimized.

Copy link
Member

floam commented Jan 21, 2019

Has anybody compared performance in fish with and without NDEBUG (disables asserts for release builds)?

@faho

This comment has been minimized.

Copy link
Member

faho commented Jan 21, 2019

@floam: Our assert isn't from assert.h, and it does not respect NDEBUG.

See src/common.h.

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Jan 22, 2019

Picked into 3.0.1 as 171ae99

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.