lkml.org 
[lkml]   [2006]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRE: [PATCH] mm: moving dirty pages balancing to pdfludh entirely
    Date
    From
    Antonio Vargas writes:
    > Maybe we should keep the sync-write logic if there is only one online
    > cpu, and thus avoiding extra context switches when they are not
    > profitable?

    A parallelism makes sense even if 1 cpu and 1 user task is there because
    of IO.
    From other hand if user thread actually does inodes write back, it may
    wait a lot (fs, jorn, io queue) events and get context switch.
    The results of 3-4 repeated runs of "/usr/bin/time -f "%c"
    iozone -i 0 -r 4 -s 1200m " in Pentium-4HT with 1GB RAM show that the
    patch is useful for 1 cpu as well as for 2:

    Old_1cpu new_1cpu
    old_2cpu new_2cpu
    /usr/bin/time %c 1932-3400 1700-3003
    1900-2728 2014-2700
    'vmstat 1' (cs/sec) 506-621 693-753 708-715
    679-752
    throughput(MB/sec) 54-58 71-94 53-59
    74-105

    Leonid

    -----Original Message-----
    From: Antonio Vargas [mailto:windenntw@gmail.com]
    Sent: Monday, July 03, 2006 9:32 PM
    To: Nikita Danilov; Ananiev, Leonid I; Linux Kernel Mailing List
    Subject: Re: [PATCH] mm: moving dirty pages balancing to pdfludh
    entirely

    On 6/28/06, Nikita Danilov <nikita@clusterfs.com> wrote:
    > Ananiev, Leonid I writes:
    > > >From Leonid Ananiev
    >
    > Hello,
    >
    > >
    > > Moving dirty pages balancing from user to kernel thread pdfludh
    entirely
    > > reduces extra long write(2) latencies, increases performance.
    > >
    >
    > [...]
    >
    > > The benchmarks IOzone and Sysbench for file size 50% and 120%
    of
    > > RAM size on Pentium4, Xeon, Itanium have reported write and mix
    > > throughput increasing about 25%. The described Iozone > 0.1 sec
    write(2)
    >
    > Results are impressive.
    >
    > Wouldn't this interfere with current->backing_dev_info logic? This
    field
    > is set by __generic_file_aio_write_nolock() and checked by
    > may_write_to_queue() to force heavy writes to do more pageout. Maybe
    > pdflush threads should set this field too?
    >
    > > latencies are deleted. The condition writeback_in_progress() is
    tested
    > > earlier now. As a result extra pdflush works are not created and
    number
    > > of context switches increasing is inside variation limites.
    >
    > Nikita.

    Maybe we should keep the sync-write logic if there is only one online
    cpu, and thus avoiding extra context switches when they are not
    profitable?

    --
    Greetz, Antonio Vargas aka winden of network
    -
    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/

    \
     
     \ /
      Last update: 2006-07-04 10:40    [W:0.047 / U:1.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site