Re: User space out of memory approach

From: Thomas Gleixner (tglx_at_linutronix.de)
Date: 01/11/05

  • Next message: Deepak Saxena: "Re: clean way to support >32bit addr on 32bit CPU"
    To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
    Date:	Tue, 11 Jan 2005 01:35:47 +0100
    
    

    On Mon, 2005-01-10 at 18:05 -0200, Marcelo Tosatti wrote:
    > The feature is interesting - several similar patches have been around with similar
    > functionality (people who need usually write their own, I've seen a few), but none
    > has ever been merged, even though it is an important requirement for many users.

    It's not a requirement for users. The current implementation in the
    kernel it's just broken, ugly code.

    > This is simple, an ordered list of candidate PIDs. IMO something similar to this
    > should be merged. Andrew ?

    I have no objections against the userspace provided candidate list
    option, but as long as the main sources of trouble

            - invocation
            - reentrancy
            - timed, counted, blah ugly protection
            - selection problem

    are not fixed properly, we don't need to discuss the inclusion of a
    userspace provided candidate list.

    Postpone this until the main problem is fixed. There is a proper
    confirmed fix for this available. It was posted more than once.

    Merging a fix which helps only 0,001 % of the users to hide the mess
    instead of fixing the real problem is a real interesting engineering
    aproach.

    I don't deny, that after the source of trouble is fixed it is worth to
    think about the merging of this addon to allow interested users to
    define the culprits instead of relying on an always imperfect selection
    algorithm.

    tglx

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Deepak Saxena: "Re: clean way to support >32bit addr on 32bit CPU"

    Relevant Pages

    • Re: Merging relayfs?
      ... relayfs client still need some ... I would prefer "unsigned int" over just "unsigned" ... In general I'm not against merging, but I have a few ideas for further ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: User space out of memory approach
      ... > userspace provided candidate list. ... > instead of fixing the real problem is a real interesting engineering ... that after the source of trouble is fixed it is worth to ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: scsi disk size reporting in dmesg
      ... >>better ask to make sure my data wouldn't get truncated when the disk got ... > The rest of the calculation does result ... I think that just hides the real problem, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 12/14] FRV: Generate more useful debug info
      ... It doesn't seem to be a problem on i386, x86_64, frv (which I'm ... When debugging, -O2 makes for a real problem because, amongst other ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: VFS: file-max limit 50044 reached
      ... >>to fix file counting anyway. ... it is Linus' call. ... right thing - fix the real problem. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)