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

Bug#426165: marked as done (apt: Could use a blocking fd to read from the pipe from dpkg)

Your message dated Sat, 8 Mar 2025 20:18:46 +0100
with message-id <5584a299-81d8-4738-bb7d-06627e005bc0@wp.pl>
and subject line Re: Bug#426165: apt: Could use a blocking fd to read from the pipe from dpkg
has caused the Debian Bug report #426165,
regarding apt: Could use a blocking fd to read from the pipe from dpkg
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
426165: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426165
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: 0.6.46.4-0.1
Severity: wishlist

Playing around with powertop, I noticed a huge amount of wake-ups while
doing some massive apt-get install. Almost 1000 wake-ups reported by
powertop.

These are due to usleep(1000) in apt-pkg/deb/dpkgpm.cc. The thing is
that apt sets the pipe from dpkg as non-blocking, and doesn't wait on
read()s, thus running into the loop and through the usleep().

This is useless and adds extra CPU wake-ups where there is no need for
it.

Simply commenting the fcntl(_dpkgin, F_SETFL, O_NONBLOCK); line makes
things cleaner, and it even seems that the install goes faster, and the
number of i/o interrupts during install gets higher than when the pipe
was non blocking, which would indicate a better throughput, too.

While this comment is enough to keep the code working while improving
things, the waitpid loop could obviously be improved a bit considering
the fd is blocking.

I can't seem to find a reason why the dpkg process would go zombie in
such case, so I think this should be safe, but you can still prove me
wrong.

Cheers,

Mike

--- End Message ---
--- Begin Message --- 
Actually closing, based on messages #10 and #15.

Kamil

--- End Message ---
Reply to: