http://lwn.net/Articles/310569/
커널 개발자들은 documentation에 대하여 굉장히 회의적이다.
Andrew의 말이 인상적이다.
"코드를 clear하게 만드는 것 보다는, 아무생각없이 단지
여기에 주석을 넣기로 되어 있으니...."
이미 TDD와 같은 방법론에서는 주석을 Andrew와 같은 이유로 주석을 금기시하기도 한다.
하지만, 어디까지나 저건 이미 guru의 반열에 오른 커널 developer들의 이야기이다.
사실, 커널 code를 exploration할 때 중간중간 주석이 없으면 굉장히 이해하기 어려운 부분들이 많이 있다. 물론 obsolete한 주석들도 많이 있긴하다. 하지만 그런 주석들로 인하여 긴 항해에서 방향을 잃지 않을 수 있을 때가 더 많이 있다는 것이 내 경험이다. 특히 kernel core 쪽은 단순한 logic이 아닌, 특정 machine에서 발생했던 regression들로 인하여, 이상한 magic code들이 들어가 있기도 하다. 이것은 커널 patch history를 follow up하지 않고 있으면 logic 상으로는 도저히 이해할 수 없는 코드들이다.
요즘은 Andrew를 비롯한 많은 kernel developer들이 git의 log의 중요성을 강조하고 있어, 문제를 보다 명확하게 logging을 하려고 하고 있어 대체적으로 만족할 만한 수준이다.
어쩌면, 나와 같은 kernel newbie들도 그런 주석에 고마워해야 할 게 아니라, 주석들로 인하여 clear되지 않고 있는 코드들에 질타를 던져야 하나...
all about documentation Dec 22, 2008
작성자: barrios 위치 9:52 AM 0 개의 덧글
레이블: linux kernel
2002 kernel trap Ingo Molnar Interview Dec 11, 2008
2002년 인터뷰 내용중 관심 있는 부분들만...
http://kerneltrap.org/node/517
Jeremy Andrews: When did you get started with Linux?
Ingo Molnar: i think i first heard
JA: What was your first contribution to the kernel?
Ingo Molnar: my very first contribution was a trivial #ifdef bugfix to the networking code, which was reviewed and merged by Alan Cox. At that point i've been lurking on the kernel mailing list for a couple of months already. My first bigger patch was to arch/i386/kernel/time.c, i implemented timestamp-counter based gettimeofday() on Pentiums (which sped up the gettimeofday() syscall by a factor of ~4) - that code is still alive in current kernels. This patch too was first reviewed by Alan Cox.
I strongly believe that a positive 'first contact' between kernel newbies and kernel oldbies is perhaps the single most important factor in attracting new developers to Linux. Besides having the ability to code, kernel developers also need the ability to talk and listen to other developers.
JA: Did you base the design on any existing scheduler implementations or research papers?
Ingo Molnar: this might sound a bit arrogant, but i have only read (most of the) research papers after writing the scheduler. This i found to be a good approach in the area of Linux - knowing about too many well-researched details can often confuse the real direction we have to take. I like writing new code, and i prefer to approach things from the physics side: take a few elementary rules and build up the 'one correct' solution, no compromises. This might not be as effective as first reading all the available material and then cherry-picking a few ideas and thinking up the remaining things, but it sure gives me lots of fun :-)
[ One thing i always try to ensure: i take a look at all existing kernel patches that were announced on the linux-kernel mailing list in the same area, to make sure there's no duplication of effort or NIH syndrome. Since such kernel mailing-list postings are progress reports of active research, it can be said that i read alot of bleeding-edge research. ]
JA: How do JVMs trigger an inefficiency in the old scheduler?
Ingo Molnar: the Java programming model prefers the use of many 'threads' - which is a valid and popular application programming model. So JVMs under Linux tend to be amongst the applications that use the most processes/threads, which are interacting in complex ways. Schedulers usually have the most work to do when there are more tasks in the systems, so JVMs tend to trigger scheduler inefficiencies sooner than perhaps any other Linux application.
JA: You're also the author of the original kernel preemption patch. How did your patch differ from the more recent work Robert Love has done in this area?
Ingo Molnar: it was a small concept-patch from early 2000 that just showed that a preemptible kernel can indeed be done by using SMP spinlocks. The patch, while it booted and appeared to work to a certain degree, had bugs and did not handle the many cases that need special care, which Robert's patches and the current 2.5 kernel handles correctly.
otherwise the base approach is IMO very similar, it has things like:
+ preempt_on();
clear_highpage(page);
+ preempt_off();
and:
+ atomic_inc_local(¤t->may_preempt); \
which is quite similar to what we have 2.5 today, with the difference that
Robert and the kernel developer community actually did the other 95% of the work :-)
JA: Are you also actively working on 2.5 preemptible kernel development?
Ingo Molnar: The maintainer is Robert - i do tend to send smaller preempt related patches (and even a larger one, the 'IRQ lock removal' patch centered around the use of the preemption count). I'm obviously interested in the topic, and i'm happy that all the seemingly conflicting concepts as lowlatency and preemption are now properly merged into 2.5 and that we have really good kernel latencies. Other pressing topics like the scheduler and the threading code still keep me busy most of the time.
JA: Your IRQ rewrite and Robert's preemptible kernel work have resulted in a unified per-task atomic count (the preempt_count) and a lot of code being cleaned up. Do you have plans to do more work in this area?
Ingo Molnar: not at the moment - right now i think that the IRQ code could hardly be any cleaner than it is today :-)
JA: What other kernel projects are you currently working on?
Ingo Molnar: mainly the scheduler, plus these days i'm working on enhancing the handling of 'threads' under Linux, utilized by the NPTL project done by glibc maintainer Ulrich Drepper. This has a high number of components that are in the 2.5 kernel already.
JA: Can you further describe the components that have already been merged into the 2.5 kernel?
Ingo Molnar: TLS stands for 'Thread Local Storage'. You can find the first announcement of the patch at:
a number of followup patches were posted, and it all got eventually merged
into 2.5.31.
Plus there were a few other things related to threading:
http://lwn.net/Articles/8131/
http://lwn.net/Articles/8034/
http://lwn.net/Articles/7618/
http://lwn.net/Articles/7617/
http://lwn.net/Articles/7603/
http://lwn.net/Articles/7411/
http://lwn.net/Articles/7408/
(note that most of the above patches got reworked significantly before they
got into the 2.5 kernel, but the concepts were all preserved.)
JA: What other Linux kernel related projects have you worked on in the past?
Ingo Molnar: here's a probably incomplete list of the bigger pieces that made it into the kernel: software-RAID support, 3-level paging on x86 (and highmem), the recent IRQ handling rewrite in 2.5 (which also removed the 'big IRQ lock'), the timer scalability patch, kernel workqueues, the CPU affinity syscalls, the initial SMP pagecache scalability code in 2.3, and i also wrote the original 'writeback pagecache' patch for 2.3, wrote various fixes and enhancements to the 'old' scheduler, wrote the 'wake one' support patch for 2.4, wrote the original zoned allocator, bootmem and mempool subsystems. Ie. all across the spectrum.
One project that is not in the 2.5 kernel is the Tux webserver (and now FTP server as well). If you want to see a Tux/FTP server that can serve 10,000 users then do:
ftp ftp.rpmfind.net
some smaller but interesting patches: the NMI watchdog, the ability of the 2.4 kernel to create more than ~4000 processes on x86 (ie. the removal of per-thread TSS), netconsole/netdump, 'big reader locks', and one older patch from 2.2 times i'm particularly proud of: i wrote the original 'current task pointer' implementation, which uses the stack pointer to get to the 'current task pointer' on SMP systems. I also wrote the 'memleak' and 'ktrace' debugging helper tools, which have been picked up by other projects.
JA: Your list of contributions is staggering!
Ingo Molnar: well, it's just that i've been around long enough, and that i'm interested in many different areas. So a colorful mix of contributions piled up.
JA: Are you still working on the Tux webserver?
Ingo Molnar: occasionally yes, but other things take precedence currently. But life has not stopped, eg. Anton Blanchard has ported Tux to 2.5, and Arjan van de Ven keeps the 2.4 patch uptodate.
JA: What still needs to be modified in the generic kernel?
Ingo Molnar: it's mainly two VFS changes, an exit()-time cleanup function and one new TCP event callback. All the 'big' features that were induced by TUX are in the 2.5 kernel already, zerocopy and the scalability work, so TUX for 2.5 is a really unintrusive patch.
JA: Of all these many impressive accomplishments, which are you the most proud?
Ingo Molnar: well, perhaps the scheduler, it manages to solve a few really hard conceptual problems in a pretty critical piece of code that already got called a couple of thousand times while eg. reading this article on a Linux box! :-)
JA: What is your background in programming prior to getting involved with Linux?
Ingo Molnar: well, like many others, i grew up on programming all possible (and even some impossible) aspects of Commodore micro-computers, since age 11. Completely knowing a greatly simplified but fully functional computer architecture helped alot in kernel development.
I think kids today have a harder time, since hardware vendors are much more tightlipped about computer internals, and the complexity of computer systems skyrocketed as well. Linux perhaps helps here too, as a central 'documentation' and reference implementation for "all computer internals that matter".
JA: Much of your work seems to be focused on improving the performance and scalability of the 2.5 kernel. Is this the result of RedHat's product requirements, or your own interests?
Ingo Molnar: well, i'm in the fortunate position that the two are a perfect match.
JA: Can you describe your development environment, including the hardware and software tools you typically use?
Ingo Molnar: i use all the normal text based kernel development tools: vim, gcc/make/etc., i use a serial line to a test-system to debug kernels, and that's all. I like it simple when reading kernel code: i use text consoles (on an LCD screen) to do most of my development work. Occasionally i drop into X for tools that make sense only there, such as ethereal or some of the BK tools.
JA: Have you worked with any other open source kernels?
Ingo Molnar: not really. I occasionally take a look at FreeBSD - some things they do right, some things they dont, in the areas i'm most interested in the Linux kernel is currently ahead both design-wise and implementation-wise. Finally we caught up in the VM subsystem as well, with Andrea's big and important 2.4 rewrite, Rik's great rmap code and Andrew's fantastic integration work. But what other answer would one expect from a Linux kernel developer? :-)
JA: FreeBSD 5.0 is due to be released around December of this year, with some significant changes to the kernel. Have you followed this development?
Ingo Molnar: not really. The things i sometimes do is to look at their code. Also, when i search for past discussions regarding some specific topic, sometimes there's a FreeBSD hit and then i read it. That's all what i can tell. But i do wish their kernel gets better just as much as the Linux kernel gets better, there needs to be competition to drive both projects forwards. (the Windows kernel is closed up enough so that it does not create any development stimulus for Linux (and vice versa). Rarely do any Windows features get discussed.)
JA: What areas of the Linux kernel do you think still lags behind FreeBSD?
Ingo Molnar: there were two areas where i think we used to lag, the VM and the block IO subsystem - both have been significantly reworked in 2.5. Whether the VM got better than FreeBSD's remains to be seen (via actual use), but the Linux VM already has features that FreeBSD does not have, eg. support for more than 4 GB RAM on x86 (here i guess i'm biased, i wrote much of that code). But FreeBSD's core VM logic itself, ie. the state machine that decides what to throw out under memory pressure, how to swap and how to do IO, is top-notch. I think with Andrew Morton's and Jens Axobe's latest VM and IO work we are top-notch as well (with a few extras perhaps).
There's also an interesting VM project in the making, Arjan van de Ven's O(1) VM code. [without doubt i do appear to have a sweet spot for O(1) code :-) ] Rik van Riel has merged Arjan's code a couple of days ago. The code converts every important VM algorithm (laundering, aging) to a O(1) algorithm while still keeping the fundamentals - this is quite nontrivial for things like page aging. It's in essence the VM overhead reduction work that Andrea Arcangeli has started in 2.4.10, brought to the extreme. I have run Arjan's O(1) VM under high memory pressure, and it's really impressive - kswapd (the central VM housekeeping kernel thread), which used to eat up lots of CPU time under VM load, has almost vanished from the CPU usage chart.
I do have the impression that the Linux VM is close to a conceptual breakthrough - with all the dots connected we now have something that is the next level of quality. The 2.5 VM has merged all the seemingly conflicting VM branches that fought it out in 2.4, and the many complex subsystems involved suddenly started playing in concert and produce something really nice.
JA: A much earlier version of the rmap code was originally in the 2.4 kernel, but got ripped out. Do you feel it has improved enough that this won't happen again?
Ingo Molnar: this most definitely wont happen. We already rely on rmap for some other features, so it's not just a matter of undoing one patch. Rmap is essential to the new VM, without rmap the VM would be like a ferrari with an old diesel motor - looks good but is pretty unusable.
the problem of rmap in 2.4 was simply its complexity, relative youth as a project and the relative low number of people that tested it. So in 2.4 it would have been quite a stretch to keep it in. But it was a fair game for 2.5, and with Andrew's simplification/robustization/speedup of Rik's rmap code it was very manageable.
JA: What other major improvements have gone into 2.5, beyond the scheduler and VM rewrites?
Ingo Molnar: the block IO rewrite, lots of VFS changes, a rework of the module code and (plug) the new threading implementation. The block IO rewrite was long overdue and that's the one i'm most happy about.
JA: Do you feel the changes are significant enough to call the next major kernel 3.0 instead of 2.6?
Ingo Molnar: well, i do think they are significant enough to be called 3.0 - on the other hand it might not matter much whether it's called 2.6 or 3.0, after all what ordinarily people know about is this new shiny Linux 9.0 release, right? ;)
JA: Looking into the future, what do you see in store for the next development kernel, version 2.7?
Ingo Molnar: no idea, really, i dont think trying to look into the future brings many fruits, the kernel needs to handle what is available here and today. Sometimes we are lucky and create stuff that happens to work for years :-) Perhaps something like OpenMosix would be nice to have in the kernel. Plus even better (native) support for User Mode Linux. Things like this.
JA: Do you have any advice to offer those aspiring to become productive kernel developers?
Ingo Molnar: only the old mantra: to read the source and the mailing lists. And take it easy - do what you like doing most.
작성자: barrios 위치 11:37 AM 0 개의 덧글
레이블: linux kernel
[PATCH] fix mapping_writably_mapped()
http://lkml.org/lkml/2008/12/10/344
이 문제는 Lee Schermerhorn에 의해 보고된 문제이다.
shared 속성의 vma를 counting하는 i_mmap_writable가 fork시에 정상적으로 counting이 되지 않고 있는 문제였다. 심지어는 음수로 가기도 한다.
이것은 Hugh가 2.6.7에서 패치하였던 __vma_link_file의 문제였다.
__vma_link_file에서 counting을 해주지 않아 발생하였던 문제이다.
어떻게 이 문제가 이제야 발견되었을까? 문제는 assert와 같은 루틴이 없었다는 것이다.
count가 음수로 가도 시스템이 계속해서 수행되었다는 것이다.
아래는 Lee가 테스트했던 방법이다.
root@dropout(root):memtoy
memtoy pid: 3301
memtoy>file /tmp/zf1
memtoy>map zf1 shared
console:__vma_link_file: vma: ffff8803fdc090b8 - mapping->i_mmap_writable: 0 -> 1
memtoy>child c1
memtoy: child c1 - pid 3302
me: I would have expected to see i_mmap_writable incremented again here, but
me: saw no console output from my instrumentation.
memtoy>unmap zf1 # unmap in parent
console:__remove_shared_vm_struct: vma: ffff8803fdc090b8 - mapping->i_mmap_writable: 1 -> 0
console:__remove_shared_vm_struct: vma: ffff8803fdc090b8 - removed last shared mapping
memtoy>/c1 show
_____address______ ____length____ ____offset____ prot share name
f 0x00007f000ae68000 0x000001000000 0x000000000000 rw- shared /tmp/zf1
me: child still has zf1 mapped
memtoy>/c1 unmap zf1 # unmap in child
console:__remove_shared_vm_struct: vma: ffff8803fe5d3170 - mapping->i_mmap_writable: 0 -> -1
--------
So, the file's i_mmap_writable goes negative. Is this expected?
If I remap the file, whether or not I restart memtoy, I see that it's
i_mmap_writable has remained negative:
-------
memtoy>map zf1 # map private [!shared] - no change in i_mmap_writable
console:__vma_link_file: vma: ffff8805fd0590b8 - mapping->i_mmap_writable: -1 -> -1
memtoy>unmap zf1 # unmap: no change in i_mmap_writable
console:__remove_shared_vm_struct: vma: ffff8805fd0590b8 - mapping->i_mmap_writable: -1 -> -1
memtoy>map zf1 shared # mmap shared, again
console:__vma_link_file: vma: ffff8805fd0590b8 - mapping->i_mmap_writable: -1 -> 0
작성자: barrios 위치 7:52 AM 0 개의 덧글
레이블: linux kernel
Corruption with O_DIRECT and unaligned user buffers Dec 4, 2008
좀 지난 얘기이긴 하지만..
현재 multiple thread의 O_DIRECT의 사용에 문제가 있다.
좀더 정확하게, multiple thread가 page 단위의 unaligned된 user buffer를 사용하게 되면
fork와 엉켜 발생하게 되는 문제이다.
예를 들어, 2개 이상의 쓰레드중 첫번째 쓰레드는 unaligned buffer의 512 offset부터 4096 byte만큼 데이터를 읽고, 2번째 쓰레드는 그 다음 4096 byte 만큼의 데이터를, 그 다음 쓰레드는 ... 차례데로 이렇게 읽어들이는 쓰레드들이 있다고 가정하자.
모든 buffer들이 512byte 만큼씩 bias되어 있다.
다음과 같은 sequence를 고려해보자.
- Thread 1이 get_user_pages를 호출했고 I/O를 issue했다.
- Fork가 발생, 해당 페이지를 COW로 mark
- Thread 2 get_user_pages 호출, I/O issue. 그러므로 이 mapping은 physical page의 사본을 얻게 된다.
- Thread 2가 issue한 I/O complete되고 새로운 데이터는 3에서 얻은 새로운 physical page에 복사
- Thread 1이 issue한 I/O complete되고 데이터는 데이터는 old phsyical page에 복사
그래서 결국 페이지의 첫 512byte의 내용은 old data를 갖게 되어 data는 사라지게 된다. -_-;
안전하게 user buffer 주소와 크기를 page boundary를 cross하게 만들지 않는 것이 좋을 것이다.
작성자: barrios 위치 11:05 AM 0 개의 덧글
레이블: linux kernel
우리라는 것 Dec 3, 2008
언젠부터인지 기억이 잘 나지 않는다.
제일 잘했던 것을 제일 못하게 되었다는 사실을 안 것은.
지금 곱씹어 보면 아마도 그 때부터가 아니었나 싶다.
하지만 더욱 안된 것은 향해가는 곳이 원하는 곳이 아니라는 점이다.
발걸음 내려놓으면 그만인 것을 구태여 돌아가고 싶지 않은 것도 있지만,
오래전 알게되었던 것들에 대한 두려움때문이기도 하다.
어느 시간, 어느 곳이 되든 절벽산책의 기분으로...
vmscan: bail out of page reclaim after swap_cluster_max pages
11/14일 Rik에 의한 패치이다.
VM은 가끔 처음 몇번의 priority동안은 inactive page들을 pormotion시키기위해 rotating back하거나 dirty page들을 sync하기 위해 I/O를 submit한다. 이것은 do_try_to_free_pages 함수에서 볼 수 있다. 그러다 결국 더 낮은 priority가 되었을 경우 너무 많은 페이지들을 회수해버리게 되는 것이다.
그래서 필요한 만큼의 페이지 회수를 완료했을 경우, 회수를 bail out하자는 것이다.
이미 이와 같은 생각은 나뿐만이 아닌 많은 사람들이 생각하고 있었다. 문제는 second-chance 알고리즘의 balancing이다. 리눅스의 페이지 회수 정책은 LRU approximation을 사용하고 있기 때문에
page referency의 정확도를 위해 효율적인 체크가 필요하다.
하지만 이와 같은 패치는 각 zone 별 referency 체크의 불균형을 가져오게 된다.
실제로 Andrew는 이와 같은 시도를 했었고, 문제를 겪었었다. 그래서 결국 그러한 패치는 revert되었었다. 또한 Mel Gorman또한 HugePage에 관한 comment를 주었다. Mel이 우려하는 것은 그 패치가 lumpy reclaim에 영향을 주어 high-order block의 회수에 영향을 줄 수 있다고 생각하기 때문이다. Lumpy reclaim은 최소한 high-order block의 base 크기만큼의 페이지 회수를 기대하고 있으나 Rik의 패치로 인하여 그렇게 되지 못할 확률이 보다 커졌기 때문이다. Mel의 테스트 결과에 의하면 테스트의 모든 machine에서 hugepage pool의 resizing을 위한 one-shot attempt은 훨씬 낮은 성공율을 보이고 있었다. 예상했던 결과이다. 하지만 multiple attempt는 결국 성공했고 aggressive한 hugepage pool의 resizing은 한 machine을 제외한 모든 machine에서 더 높은 성공률을 보였다. Mel은 Rik의 패치에 대해서 몇가지 질문들을 하였다.
- 기존에 있는 baleout 루틴은 너무 늦나?? 그럼 삭제되야 하나? 이 루틴도 do_try_to_free_pages 함수안에 있다.
- reclaim을 덜하게 되는 것은 결국 page aging을 old하게 만드는 것이다
작성자: barrios 위치 8:09 AM 0 개의 덧글
레이블: linux kernel
Skip freeing memory from zones with lots free Dec 1, 2008
Rik은 새로운 패치를 submit하였으나 Andrew는 별로 달가워 하지 않는다.
패치의 골자는 어떤 memory zone에서 free memory를 찾기 어려울 경우, 다른 zone으로부터의 과도한 memory free를 피하자는 것이다. 왜냐하면 다른 memory zone으로부터의 pageout I/O는 문제의 zone에서 page를 free하는 것을 느리게 만들기 때문이다.
이는 이미 kswapd의 balance_pgdat에서 하고 있는 것과 유사하다.
note_zone_scanning_priority(zone, priority);
/*
* We put equal pressure on every zone, unless one
* zone has way too many pages free already.
*/
if (!zone_watermark_ok(zone, order, 8*zone->pages_high,
end_zone, 0))
nr_reclaimed += shrink_zone(priority, zone, &sc);
reclaim_state->reclaimed_slab = 0;
nr_slab = shrink_slab(sc.nr_scanned, GFP_KERNEL,
lru_pages);
nr_reclaimed += reclaim_state->reclaimed_slab;
이 패치에 대해 Peter Zijlstra나 Johannes Weiner는 Ack를 한 상태지만,
마지막 뒷다리를 잡은 것은 역시나 Andrew였다.
Andrew는 이미 그와 유사한 시도를 2002년도에 이미 했었다.
commit 26e4931632352e3c95a61edac22d12ebb72038fe
Author: akpm
Date: Sun Sep 8 19:21:55 2002 +0000
[PATCH] refill the inactive list more quickly
Fix a problem noticed by Ed Tomlinson: under shifting workloads the
shrink_zone() logic will refill the inactive load too slowly.
Bale out of the zone scan when we've reclaimed enough pages. Fixes a
rarely-occurring problem wherein refill_inactive_zone() ends up
shuffling 100,000 pages and generally goes silly.
This needs to be revisited - we should go on and rebalance the lower
zones even if we reclaimed enough pages from highmem.
Then it was reverted a year or two later:
commit 265b2b8cac1774f5f30c88e0ab8d0bcf794ef7b3
Author: akpm
Date: Fri Mar 12 16:23:50 2004 +0000
[PATCH] vmscan: zone balancing fix
We currently have a problem with the balancing of reclaim between zones: much
more reclaim happens against highmem than against lowmem.
This patch partially fixes this by changing the direct reclaim path so it
does not bale out of the zone walk after having reclaimed sufficient pages
from highmem: go on to reclaim from lowmem regardless of how many pages we
reclaimed from lowmem.
위의 글에서 보는 것과 같이 그러한 패치는 revert되었다. 왜냐하면 lowmem보다 highmem의 scanning 비율이 커지면서 page reclaiming 쪽의 zone의 scanning 불균형이 온 것이다.
이에 대해 Rik은 다시 balance_pgdat도 이미 유사한 것을 하고 있고 지금까지 side effect 없이 잘 사용해왔다고 밝히고, Andrew의 패치와는 달리 이것은 baleout이 아니고 "이미 많은 free page를 가지고 있는 zone을 skip"하자는 것이라고 강조했다.
Andrew는 이에 대해 하지만 Rik의 패치는 kswapd뿐만 아니라 direct reclaim에도 영향을 줄 수 있다고 말하며 bale out과 skip은 유사한 영향을 줄 것이라고 답변했다. 하지만 이번에는 Andrew가 틀렸다. kswapd는 shrink_zone을 direct로 호출하지 shrink_zones을 통하지 않는다. 그러므로 Rik의 패치는 kswapd에는 영향을 주지 않게 된다.
어쨌든, Rik의 패치가 zone scanning ratio에 문제를 주는 것은 사실이다.
이에 대해, Rik은 각 zone마다 같지 않은 allocation pressure로 인하여 때론 같지 않은 pressure가 바람질할 때도 있다고 반박하고 있다. 일리가 있는 말이다.
lowmem에 대한 allocation요구가 많을 때, highmem에 page를 swapout하는 것은 바람직하지 않다. 또는 numactl로 pinned된 application이 다른 NUMA node에 page를 swapout하게 하는 것은 바람직하지 않다.
또한 이미 balance_pgdat에서는 그와 같은 scannng imbalance를 만드는 코드가 들어가 있다.
if (!zone_watermark_ok(zone, order, zone->pages_high,
0, 0)) {
end_zone = i;
break;
}
하지만 양자간의 아직까지 의견일치가 되고 있지 않다.
Rik이 Andrew를 설득시키지 못하는 한 이 패치는 반영되지 않을 것이다.
Note :
- Direct reclaim은 zonelkist에 모든 zone의 free page가 zone->pages_low이하로 떨어지지 않으면 들어가지 않는다.
- old kernel git treee : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git
작성자: barrios 위치 8:05 AM 0 개의 덧글
레이블: linux kernel
