Re: Blocking read() policy?

From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 07/21/05

  • Next message: David Schwartz: "Re: Blocking read() policy?" 
    Date: Thu, 21 Jul 2005 17:59:17 +0200

    Robert Redelmeier wrote:
    >
    > Kasper Dupont <kasperd@daimi.au.dk> wrote:
    > > No, that is not a good enough reason to preempt the process.
    >
    > Wasting resources polling isn't bad?

    Sure, but making the kernel more complicated for no
    good reason is worse.

    >
    > > Detecting this situation would be very complicated, just counting
    > > system calls would lead to false positives. The very limited
    > > value of this feature does not justify the hughe complexity it
    > > would require to implement this correctly in the kernel.
    >
    > What's tough about keeping a rolling list of RDTSC words for
    > stupid syscalls (read() null returns) and calling the scheduler
    > if too few cycles have elapsed since the Yth previous?

    You will be wasting memory on the the list, you will
    be wasting CPU time on keeping it updated and
    performing the checks. You will not know what the
    right values for number of calls and time should be.
    You will end up with false positives blocking
    processes that shouldn't have been blocked.

    And depending on the exact implementation those false
    positives will lead to very poor performance or even
    deadlocks.

    >
    > > Exactly. Any program behaving the way you describe is
    > > buggy. The correct solution to any such problem is to fix
    > > the bug in the application.
    >
    > Ideally, yes.
    >
    > > As long as it doesn't hurt the integrity of the system,
    > > the kernel shouldn't worry about buggy programs.
    >
    > Yes, this is one approach. But does not lead to
    > system optimization.

    What is better? The current approach where only buggy
    applications waste resources, or your approach where
    the kernel will waste resources even when all
    applications are well behaved?

    >
    > >> But I haven't seen anyone suggest it.
    > > For good reasons.
    >
    > I was referring to "fixing pgms", not rescheduling.

    Do you know any widely used application with such a
    bug? 

    -- 
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.
  • Next message: David Schwartz: "Re: Blocking read() policy?"

    Relevant Pages

    • Re: Why healthcare in the U.S. is "expensive" (and why Andres a lumberjack hes ok...)
      ... the USPS and UPS/Fed Ex which was not about cost. ... "Belief" being the operative word here. ... the only reason the USPS doesn't have to concern itself with Customer ... monopolies are efficient distributors of shared resources ...
      (soc.men)
    • Re: Earthquakes and Arcologies
      ... Brian Davis wrote: ... reason to build it a lot stronger and more survivable than we might ... You only build things to mil-spec if survivability is ... unlimited resources, then I agree that over-engineering everything is ...
      (rec.arts.sf.science)
    • Re: Pure Time Travel Stories?
      ... >> Nancy Lebovitz wrote: ... You have to fit in the magic as a reason. ... >> use the same natural resources, so ... > Why on earth would they have a statue there? ...
      (rec.arts.sf.written)
    • Re: Failed 70-292 and 70-296 today
      ... > I fell that the only good reasons for passing these certifications are: ... > as claimed by Microsoft). ... > If anyone has another good reason, maybe I will give it another try. ... Besides finding a decent manual, using Online web resources from TechNet, ...
      (microsoft.public.cert.exam.mcse)
    • Re: I want to buy a green Nobels ODR-S Overdrive pedal
      ... doing is wasting your time. ... that's more than most of you old over the hill fuckers can say. ... There's no point trying to reason with these fuckers, ... talkin to the idiots in this forum is like talkin ...
      (alt.guitar)
    Loading