ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   07 Mar 2002  17:14:41
 To : All
 Subject : URL: http://www.lwn.net/2002/0307/kernel.php3
 -------------------------------------------------------------------------------- 
 

    [1][LWN Logo] [2][oasisi.php?s=5&w=468&h=60] 
    [LWN.net]
 
    Sections:
     [3]Main page
     [4]Security
     Kernel
     [5]Distributions
     [6]Development
     [7]Commerce
     [8]Linux in the news
     [9]Announcements
     [10]Letters
    [11]All in one big page
 
    See also: [12]last week's Kernel page.
 
 Kernel development
 
    The current development kernel release is 2.5.5. Linus's latest
    prepatch is [13]2.5.6-pre3; it contains a fair amount in the way of
    fixes and updates, but the most visible change will be the integration
    of the JFS journaling filesystem from IBM. Also included are ARM and
    X86-64 updates, USB updates, VFS updates, IDE driver reworking (see
    below), a parport update, and more.
 
    Dave Jones's latest prepatch is [14]2.5.5-dj3. It is caught up to
    2.5.6-pre2 and 2.4.19-pre2, and throws in several more fixes as well.
 
    Guillaume Boissiere's [15]2.5 status summary for March 6 is available.
 
    The current stable kernel release is 2.4.18. The current 2.4.19
    prepatch from Marcelo is [16]2.4.19-pre2. It contains the struct page
    shrinkage patch, but otherwise confines itself to fixes and cleanups.
 
    Alan Cox's current prepatch is [17]2.4.19-pre2-ac2; the most
    significant addition in that patch is Ingo Molnar's O(1) scheduler,
    which has been in the 2.5 series for some time. Also from Alan is
    [18]2.4.18-ac3, which adds a much smaller set of fixes to 2.4.18.
 
    Other kernel trees which have been released in the past week include:
      * Andrea Arcangeli's [19]2.4.19-pre1-aa1 includes the latest version
        of his VM code which will probably be heading for Marcelo's tree
        before too long. (Andrea has [20]proposed it for inclusion, but
        Marcelo has [21]asked for it to be split into small, documented
        pieces).
      * Joerg Prante has released [22]2.4.18-jp6, a heavily patched
        version of 2.4.18. Among other things, it includes the new VM and
        scheduler, the preemptable kernel patch, the new IDE driver,
        FreeS/Wan, XFS, JFS, and the lm_sensors patch. (Note that
        lm_sensors can, apparently, be fatal to some IBM laptops).
      * [23]2.4.19-pre2-jam2 comes from J.A. Magallon; it merges the
        latest Arcangeli VM and a couple of other patches.
      * The contender for the longest name is
        [24]2.4.19-pre2-ac2-xfs-shawn9 from Shawn Starr; it is a mixture
        of Rik van Riel's reverse mapping VM and SGI's XFS filesystem.
        (Here's [25]where to get it.)
 
    How clean should the IDE code get? A regular feature on the
    linux-kernel list over the last few weeks has been a series of "IDE
    cleanup" patches by Martin Dalecki. These patches have been aimed at
    making the IDE driver code easier to read, and at removing duplicated
    and unnecessary code. They have been, for the most part,
    uncontroversial, and Linus has merged most of them into his recent
    releases. (Of course, Andre Hedrick, the author of much of the IDE
    code, [26]is not pleased with this work, but that's a story in its own
    right...)
 
    Things changed a bit, however, with the posting of [27]IDE cleanup 16
    which, among other things, takes away direct access (via ioctl()) to
    the IDE taskfile commands. Martin didn't like providing the ability
    for userspace programs to talk to the drives directly in that manner,
    and he complained about the command parsing code that was there as
    part of that functionality. According to Martin, the taskfile ioctl
    has only been there since 2.5.3, and is used by nobody.
 
    That reasoning ignores one important little fact: Andre's IDE patches
    have been around for some time, and have been extensively used despite
    the fact that they only now have found their way into a mainline
    kernel. There are users who [28]have found reasons to employ the
    TASKFILE interface, and they are not pleased at its disappearance. To
    many, this change goes beyond a simple "cleanup."
 
    Martin seems to have come to agree that some sort of taskfile access
    is necessary. That issue will thus probably come to a resolution, but
    there is still a larger question that needs answering. Martin appears
    to have performed a hostile takeover of the maintainership of the IDE
    code. Is he truly the IDE maintainer now, and how far does his mandate
    for change extend?
 
    Protesting BitKeeper. The only surprise is how long it took for this
    to happen. A group of Ohio State students has [29]posted a petition
    protesting the increasing use of BitKeeper by the kernel development
    community. In particular, the petitioners fear that the day will come
    when use of BitKeeper will be required to participate in the kernel
    development process.
 
    The problem, of course, is that the BitKeeper license is not a free
    software license. The BitKeeper source (or a version of it, anyway) is
    available, and modifications and redistribution are allowed. But there
    are certain things that you can not do (in particular: disabling the
    "open logging" feature); thus the software is not free. (See [30]LWN's
    1999 BitKeeper coverage or [31]Jack Moffitt's critique of the
    BitKeeper license for more information).
 
    The response to the petition has ranged from [32]weak to [33]hostile.
    There are certainly kernel hackers who choose not to use BitKeeper as
    a result of its licensing, but few seem to be worried about their
    continued ability to contribute, and none feel the need to impose
    their decisions on others. BitKeeper seems to be winning converts in
    the kernel development community, and petitions are unlikely to change
    that.
 
    Linux device number registration resumes. Back in May of 2001, Linus
    decreed that no more major device numbers would be handed out; his
    goal was to force the kernel developers to come up with a reasonable
    alternative to static numbers. Now John Cagle, who has taken over
    management of the Linux device list, has [34]announced that device
    number registrations will resume - at least for kernels released by
    Marcelo Tosatti and Alan Cox (i.e. in the 2.4 series). Linus is
    presumably still not accepting new numbers for 2.5, so any numbers
    allocated now could well not show up in 2.6 until Linus passes it on
    to a new maintainer.
 
    (See [35]the May 17, 2001 LWN Kernel Page for coverage of the
    moratorium on new device numbers).
 
    Delayed disk block allocation. When a Linux process writes data to a
    disk file, the kernel calls into the appropriate filesystem code to
    get disk space allocated for that data. This allocation happens even
    though the kernel could (and often does) decide to not actually write
    that data to disk for some time. The early allocation offers
    simplicity and reliability - it is nice to know where the data will
    eventually end up - and it has been good enough for the Linux kernel
    until now.
 
    Early allocation is not ideal, however, for a few reasons. Foremost
    among those is that early allocation makes it hard for the filesystem
    code to optimize the layout of files on disk. The best performance is
    achieved when the blocks of a file are placed contiguously on the
    disk; they can then be read or written in a single, fast operation. If
    the filesystem allocates new blocks one at a time, however, contiguous
    placement can be hard to accomplish. In particular, if multiple
    processes are writing files in the same filesystem simultaneously,
    their data may end up being interleaved on the disk.
 
    Another worthwhile consideration is that some files never get written
    to disk at all. Many applications create short-lived temporary files
    that are deleted before their blocks are ever committed to the drive.
    For such files, it is better to never bother with the allocation of
    blocks at all.
 
    These concerns argue for delaying the allocation of blocks for files
    until it is absolutely necessary. A proper delayed allocation
    implementation should have a measurable impact on performance. That
    assertion has now been put to the test, as Andrew Morton has
    [36]posted a patch implementing delayed allocation for the 2.5.6-pre
    kernels.
 
    Delayed allocation, of course, requires cooperation from the
    filesystem code, since that is where the allocation actually occurs.
    It is important, after all, to know that the required disk blocks will
    be available when the system finally does get around to allocating
    them - applications want to know right away if their writes are not
    going to work. Andrew's patch thus extends the
    address_space_operations structure with a few new methods. When a
    process writes into a new file block, the kernel can call the
    reservepage method to tell the filesystem to set some space aside.
    Later on, the new writeback_mapping method can be called to commit
    blocks to disk, allocating the space at that time.
 
    A fair amount of effort (and code) has gone into trying to handle
    those writebacks in an intelligent way. A set of tunable thresholds
    determine when (and to what extent) the kernel will go out of its way
    to write dirty pages to disk. At the lowest level, writebacks will
    start happening as a kernel background task. If the number of dirty
    pages reaches a substantial portion of the total, processes performing
    writes can be blocked while their pages are written out synchronously.
 
    Much of the writeout is intended to happen in the background mode,
    however. To this end, the delayed allocation patch introduces yet
    another set of kernel threads, called "pdflush." The number of pdflush
    threads will go up as the amount of writeback work increases - their
    number is managed through a simple, apache-style pool scheme. The
    purpose of having multiple threads is to try to keep multiple disk
    devices busy, even if one is doing most of the work.
 
    How well does the patch work? Randy Hron, kernel benchmarker
    extraordinaire, has compiled [37]an extensive set of results. The
    bottom line: for disk operations, and heavy writes in particular, the
    delayed allocation patch increases performance by 20-25%. Probably
    worth the trouble, in other words. As [38]one kernel hacker put it:
    "My only comment is: how fast can we get delalloc into 2.5.x for
    further testing and development?"
 
    Other patches and updates released this week include:
 
    Core kernel code:
      * Robert Love has posted mechanisms for setting task processor
        affinities [39]via /proc and [40]with system calls. He has also
        posted [41]a small test program which exercises the system call
        interface.
      * Also from Robert is [42]a new preemptive kernel patch for the 2.4
        series.
      * A new radix-tree page cache patch for 2.4.x was [43]posted by
        Christoph Hellwig.
      * Tim Schmielau has posted [44]a patch (with [45]a second part)
        which enables 32-bit systems to display uptimes greater than 497
        days.
 
    Development tools:
      * [46]ksymoops 2.4.4 has been released by Keith Owens.
 
    Device drivers
      * Gerd Knorr has [47]posted the third iteration of his video device
        redesign. He's looking for comments soon before he sends the patch
        to Linus.
      * David Miller has [48]announced the sixth beta version of the new
        Tigon3 driver.
 
    Filesystems:
      * A new [49]access control list patch has been posted by Andreas
        Gruenbacher.
      * Craig Christophel has [50]announced an extensive set of patches
        (actually written by Jan Kara) which pp completely rework the
        Linux disk quota subsystem.
 
    Miscellaneous:
      * Jeff Dike has released [51]User-mode Linux 0.55-2.4.18. There's a
        lot of new stuff in this release, including features which make it
        (hopefully) secure against a hostile root user.
      * [52]Kernel Traffic for March 4 is available.
      * Here's [53]the latest maintainers file from Denis Vlasenko.
      * The latest [54]fast user-space mutexes ("futexes") patch is
        available from Rusty Russell.
      * Jari Ruusu has posted [55]version v1.5c of the loop-AES crypto
        package.
      * A "linmodem" driver for Conexant HCF chipsets has been [56]posted
        (in beta form) by Marc Boucher.
 
    Networking:
      * [57]Version 0_94 of the Affix BlueTooth stack was announced by
        Dmitry Kasatkin.
 
    Section Editor: [58]Jonathan Corbet
    March 7, 2002
 
    For other kernel news, see:
      * [59]Kernel traffic
      * [60]Kernel Newsflash
      * [61]Kernel Trap
      * [62]Linux 2.5.x Porting help
      * [63]2.5 Status
    
    Other resources:
      * [64]Kernel Source Reference
      * [65]L-K mailing list FAQ
      * [66]Linux-MM
      * [67]Linux Scalability Effort
      * [68]Kernel Newbies
      * [69]Linux Device Drivers
    
    
 
                                                   [70]Next: Distributions
 
    [71]Eklektix, Inc. Linux powered! Copyright Л 2002 [72]Eklektix, Inc.,
    all rights reserved
    Linux (R) is a registered trademark of Linus Torvalds
 
 References
 
    1. http://lwn.net/
    2. http://oasis.lwn.net/oasisc.php?s=5&w=468&h=60
    3. http://lwn.net/2002/0307/
    4. http://lwn.net/2002/0307/security.php3
    5. http://lwn.net/2002/0307/dists.php3
    6. http://lwn.net/2002/0307/devel.php3
    7. http://lwn.net/2002/0307/commerce.php3
    8. http://lwn.net/2002/0307/press.php3
    9. http://lwn.net/2002/0307/announce.php3
   10. http://lwn.net/2002/0307/letters.php3
   11. http://lwn.net/2002/0307/bigpage.php3
   12. http://lwn.net/2002/0228/kernel.php3
   13. http://lwn.net/2002/0307/a/2.5.6-pre3.php3
   14. http://lwn.net/2002/0307/a/2.5.5-dj3.php3
   15. http://lwn.net/2002/0307/a/2.5-status.php3
   16. http://lwn.net/2002/0307/a/2.4.19-pre2.php3
   17. http://lwn.net/2002/0307/a/2.4.19-pre2-ac2.php3
   18. http://lwn.net/2002/0307/a/2.4.18-ac3.php3
   19. http://lwn.net/2002/0307/a/2.4.19-pre1-aa1.php3
   20. http://lwn.net/2002/0307/a/vm-28.php3
   21. http://lwn.net/2002/0307/a/mt-vm-28.php3
   22. http://lwn.net/2002/0307/a/2.4.18-jp6.php3
   23. http://lwn.net/2002/0307/a/2.4.19-pre2-jam2.php3
   24. http://lwn.net/2002/0307/a/2.4.19-pre2-ac2-xfs-shawn9.php3
   25. http://lwn.net/2002/0307/a/shawn9-where.php3
   26. http://lwn.net/2002/0307/a/ah-cleanups.php3
   27. http://lwn.net/2002/0307/a/cleanup-16.php3
   28. http://lwn.net/2002/0307/a/ac-taskfile.php3
   29. http://lwn.net/2002/0307/a/bitkeeper-petition.php3
   30. http://lwn.net/1999/features/BitKeeper.php3
   31. http://i.cantcode.com/writing/bitkeeper.html
   32. http://lwn.net/2002/0307/a/am-bk.php3
   33. http://lwn.net/2002/0307/a/av-bk.php3
   34. http://lwn.net/2002/0307/a/lanana.php3
   35. http://lwn.net/2001/0517/kernel.php3
   36. http://lwn.net/2002/0307/a/delayed-allocation.php3
   37. http://home.earthlink.net/~rwhron/kernel/akpm.html
   38. http://lwn.net/2002/0307/a/how-fast.php3
   39. http://lwn.net/2002/0307/a/proc-affinity.php3
   40. http://lwn.net/2002/0307/a/syscall-affinity.php3
   41. http://lwn.net/2002/0307/a/affinity.c.php3
   42. http://lwn.net/2002/0307/a/preempt.php3
   43. http://lwn.net/2002/0307/a/radix-tree.php3
   44. http://lwn.net/2002/0307/a/uptime.php3
   45. http://lwn.net/2002/0307/a/uptime2.php3
   46. http://lwn.net/2002/0307/a/ksymoops.php3
   47. http://lwn.net/2002/0307/a/videodev.php3
   48. http://lwn.net/2002/0307/a/tigon.php3
   49. http://lwn.net/2002/0307/a/acl.php3
   50. http://lwn.net/2002/0307/a/quota.php3
   51. http://lwn.net/2002/0307/a/uml.php3
   52. http://kt.zork.net/kernel-traffic/kt20020304_156.html
   53. http://lwn.net/2002/0307/a/maintainers.php3
   54. http://lwn.net/2002/0307/a/futexes.php3
   55. http://lwn.net/2002/0307/a/loop-aes.php3
   56. http://lwn.net/2002/0307/a/linmodem-hcf.php3
   57. http://lwn.net/2002/0307/a/affix.php3
   58. mailto:lwn@lwn.net
   59. http://kt.zork.net/
   60. http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
   61. http://www.kerneltrap.com/
   62. http://www.osdl.org/archive/rddunlap/linux-port-25x.html
   63. http://kernelnewbies.org/status/
   64. http://lksr.org/
   65. http://www.tux.org/lkml/
   66. http://www.linux.eu.org/Linux-MM/
   67. http://lse.sourceforge.net/
   68. http://www.kernelnewbies.org/
   69. http://www.xml.com/ldd/chapter/book/index.html
   70. http://lwn.net/2002/0307/dists.php3
   71. http://www.eklektix.com/
   72. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор