Re: 2.6.4-mm2

From: Miquel van Smoorenburg (miquels_at_cistron.net)
Date: 03/19/04

  • Next message: Nick Piggin: "Re: [BENCHMARKS] 2.6.4 vs 2.6.4-mm1"
    To: akpm@osdl.org
    Date:	Fri, 19 Mar 2004 10:56:35 +0100
    
    

    In article <20040318235200.25c376a9.akpm@osdl.org> you write:
    >Jens Axboe <axboe@suse.de> wrote:
    >> I thought about this last night, and I have a better idea that gets the
    >> same accomplished. The problem right now is indeed that we aren't
    >> tracking who needs to be unplugged, like we used to. The solution is to
    >> do the exact same style plugging (with block helpers) that we used to,
    >> except the plug_list is maintained in the driver. So when you do
    >> dm_unplug(), it doesn't _have_ to iterate the full device list, only
    >> those that do need kicking.
    >
    >Yes, it would be nice but I fear that it gets complicated.
    >
    >Is it not the case that two dm maps can refer to the same queue? Say, one
    >map uses /dev/hda1 and another map uses /dev/hda2?
    >
    >If so, then when the /dev/hda queue is plugged we need to tell both the
    >higher-level maps that this queue needs an unplug. So blk_plug_device()
    >and the various unplug functions need to perform upcalls to an arbitrary
    >number of higher-level drivers, and those drivers need to keep track of the
    >currently-plugged queues without adding data structures to the
    >request_queue structure.
    >
    >It can be done of course, but could get messy.

    I implemented exactly this for the congestion stuff. It
    isn't perfect, but perhaps it is of some use:
                                                                                    
    https://www.redhat.com/archives/linux-lvm/2004-February/msg00215.html

    It got shot down because it was too complicated..

    Mike.

    -- 
    Netu, v qba'g yvxr gur cynvagrkg :)
    -
    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: Nick Piggin: "Re: [BENCHMARKS] 2.6.4 vs 2.6.4-mm1"

    Relevant Pages

    • Re: 2.6.4-mm2
      ... > number of higher-level drivers, and those drivers need to keep track of the ... > currently-plugged queues without adding data structures to the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC PATCH] explicitly mark recursion count
      ... I could hack up something that will generate digests from the function ... If you've chosen the right data structures and organized ... the algorithms will almost always be self-evident. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6 sendfile
      ... > can change the existing source code according to my needs.Can someone help ... If you've chosen the right data structures and organized ... the algorithms will almost always be self-evident. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: What does tainting actually mean?
      ... > The problem is with corrupted data structures, pointers, etc. ... namely the device driver author. ... I prefer open source modules (I ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [ACPI] Re: [PATCH/RFC] exposing ACPI objects in sysfs
      ... > emulation problem is limited to an ILP32 application generating data ... > structures appropriate for an LP64 kernel. ... more like a LP64 kernel getting data structures a ILP32 application ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)

    Loading