[번역] vm/slub.txt

SLUB에 대한 간단한 유저가이드(Short users guide for SLUB)

SLUB의 기본 철학은 SLAB과 매우 다르다. SLAB는 모든 슬랩 캐시에 대한 디버그 옵션을 활성화하기 위해 커널을 다시 빌드해야 한다. SLUB은 항상 전체 디버깅을 포함하지만 기본적으로 해제되어 있다. SLUB은 전체 시스템 성능에 대한 영향을 피하기 위해 선택한 슬랩에 대해서만 디버깅을 활성화 할 수 있으므로 버그를 찾기가 더 어려워 질 수 있다.

The basic philosophy of SLUB is very different from SLAB. SLAB requires rebuilding the kernel to activate debug options for all slab caches. SLUB always includes full debugging but it is off by default. SLUB can enable debugging only for selected slabs in order to avoid an impact on overall system performance which may make a bug more difficult to find.

디버깅을 전환하려면 “slub_debug”옵션을 커널 명령 행에 추가하면 된다. 그러면 모든 슬랩에 대해 전체 디버깅이 가능하다.

In order to switch debugging on one can add an option “slub_debug” to the kernel command line. That will enable full debugging for all slabs.

슬랩에 대한 통계 데이터를 얻고 슬랩에 작업을 수행하기 위해 보통 “slabinfo”를 사용한다. 기본적으로 slabinfo는 데이터가 들어있는 슬랩만 나열한다. 명령 실행시 추가 옵션은 “slabinfo -h”를 참조하자. slabinfo를 컴파일하려면 아래와 같이 하면된다.

Typically one would then use the “slabinfo” command to get statistical data and perform operation on the slabs. By default slabinfo only lists slabs that have data in them. See “slabinfo -h” for more options when running the command. slabinfo can be compiled with

gcc -o slabinfo tools/vm/slabinfo.c

slabinfo의 일부 동작 모드는 커맨드라인(커널 부트파라미터)에 slub debugging을 활성화하길 요구한다. F.e. slub debugging이 활성화되지 않고서는 추적 정보를 사용할 수 없으며 디버깅이 켜지지 않은 경우에는 부분적인 유효성 검사만 수행 될 수 있다.

Some of the modes of operation of slabinfo require that slub debugging be enabled on the command line. F.e. no tracking information will be available without debugging on and validation can only partially be performed if debugging was not switched on.

좀 더 정교한 slub_debug 사용법(Some more sophisticated uses of slub_debug)

slub_debug에 파라미터를 사용할 수 있다. 파라미터를 지정하지 않으면 full debugging이 활성화된다. 파라미터의 형식은 아래와 같다.

Parameters may be given to slub_debug. If none is specified then full debugging is enabled. Format:

slub_debug=<Debug-Options>

모든 슬랩에 적용되는 옵션을 활성화함(Enable options for all slabs)

slub_debug=<Debug-Options>,<slab name>

특정 슬랩에 적용되는 옵션을 활성화함(Enable options only for select slabs)

사용가능한 디버깅 옵션은 아래와 같다.(Possible debug options are)

• ‘F’ – sanity check 활성화(Sanity checks on)
• SLAB_DEBUG_CONSISTENCY_CHECKS를 활성화한다(enables SLAB_DEBUG_CONSISTENCY_CHECKS Sorry SLAB legacy issues)
• ‘Z’ – 레드존 기능을 활성화(Red zoning)
• ‘P’ – 포이즈닝 기능을 활성화(Poisoning (object and padding))
• ‘U’ – 슬랩 할당/해제를 추적하는 기능을 활성화(User tracking (free and alloc))
• ‘T’ – 슬랩을 추적하는 기능을 활성화(Trace (please only use on single slabs))
• ‘A’ – ??(Toggle failslab filter mark for the cache)
• ‘O’ – 최소 slab order를 증가시킬 우려가 있는 슬랩캐시에 대한 디버깅을 비활성화함(Switch debugging off for caches that would have caused higher minimum slab orders)
• ‘-‘ – 모든 디버깅 기능 비활성화(Switch all debugging off)
• 커널이 사용하는 CONFIG_SLUB_DEBUG_ON을 비활성화할 때 유용함 (useful if the kernel is configured with CONFIG_SLUB_DEBUG_ON))

예를 들어 sanity 체크와 red zone 만 활성화해서 부팅하기 위해서는 아래와 같이 설정한다.

F.e. in order to boot just with sanity checks and red zoning one would specify:

slub_debug=FZ

dentry 캐시의 문제를 찾기 위해서는 아래와 같이 설정한다.

Trying to find an issue in the dentry cache? Try

slub_debug=,dentry

위와 같이 설정하면 dentry 캐시에 대해서만 디버깅할 수 있다.

to only enable debugging on the dentry cache.

red zone을 활성화하고 추적하는 것은 slab을 재정렬?할 수 있다. 아래와 같이 설정하면 dentry 캐시에만 sanity 체크를 활성화할 수 있다.

Red zoning and tracking may realign the slab. We can just apply sanity checks to the dentry cache with

slub_debug=F,dentry

디버깅 옵션은 메타 데이터(예를 들어, caches with PAGE_SIZE objects sizes) 를 저장하기 위해 결과적으로 slab order를 증가시키는 걸 필요로 할수도 있다. 이런 상황은 메모리가 부족한 상황이나 메모리 단편화가 심한 상황에서 슬랩 할당에러가 발생할 확률을 높힌다. 이런 캐시에 대한 디버깅을 비활성화하려면 아래와 같이 설정한다.

Debugging options may require the minimum possible slab order to increase as a result of storing the metadata (for example, caches with PAGE_SIZE object sizes). This has a higher liklihood of resulting in slab allocation errors in low memory situations or if there’s high fragmentation of memory. To switch off debugging for such caches by default, use

slub_debug=O

커널 커맨드 라인에서 디버깅을 활성화하는 것을 잊어버린 경우: 커널이 동작중일 때 수동으로 디버깅을 활성화할 수 있다. 아래 경로의 내용을 살펴보자.

In case you forgot to enable debugging on the kernel command line: It is possible to enable debugging manually when the kernel is up. Look at the contents of:

/sys/kernel/slab/<slab name>/

write 가능한 파일을 보자. 1을 쓰면 해당 디버그 옵션이 활성화된다. 모든 옵션은 오브젝트가 포함되지 않은 슬랩에 설정할 수 있다. 슬랩에 이미 오브젝트가 있다면 sanitize 체크와 추적을 사용할 수 있다. 다른 옵션을 사용하면 오브젝트의 realign이 발생할 수 있다.

Look at the writable files. Writing 1 to them will enable the corresponding debug option. All options can be set on a slab that does not contain objects. If the slab already contains objects then sanity checks and tracing may only be enabled. The other options may cause the realignment of objects.

주의깊게 추적해야 한다.  많은 정보가 출력될 수 있으며 잘못된 슬랩에 사용하면 멈추지 않을 수 있다.

Careful with tracing: It may spew out lots of information and never stop if used on the wrong slab.

슬랩 캐시 통합기능(Slab merging)

디버그 옵션을 사용하지 않으면 SLUB은 오버 헤드를 줄이고 오브젝트의 cache hotness를 높이기 위해 유사한 슬랩을 병합 할 수 있다. slabinfo -a는 어떤 슬랩이 함께 병합되었는지 표시한다.

If no debug options are specified then SLUB may merge similar slabs together in order to reduce overhead and increase cache hotness of objects. slabinfo -a displays which slabs were merged together.

슬랩 유효성(Slab validation)

SLUB은 slub_debug로 커널을 부팅 한 경우 모든 오브젝트의 유효성을 검사 할 수 있다. 그렇게 하려면 slabinfo 도구가 있어야한다. 도구를 구하면 아래와 같이 사용할 수 있다.

SLUB can validate all object if the kernel was booted with slub_debug. In order to do so you must have the slabinfo tool. Then you can do

slabinfo -v

위 명령어는 모든 슬랩 오브젝트의 유효성을 체크한다. 체크 결과는 syslog로 출력된다.

which will test all objects. Output will be generated to the syslog.

slab debug 없이 부팅된 경우 이 방법은 더 제한된 방식으로 작동한다. 이 경우 slabinfo -v는 모든 도달 가능한 오브젝트를 테스트한다. 보통 이들은 CPU 슬랩과 partial 슬랩에 있다. SLUB는 디버그가 활성화되지 않은 상황에서는 전체 슬랩을 추적하지 않는다.

This also works in a more limited way if boot was without slab debug. In that case slabinfo -v simply tests all reachable objects. Usually these are in the cpu slabs and the partial slabs. Full slabs are not tracked by SLUB in a non debug situation.

슬랩 성능 높히기(Getting more performance)

슬럽의 성능은 partial 슬랩을 처리하는 동안에 잡아야 하는 list_lock에 의해 약간 제한된다. 그 오버 헤드는 각 슬랩에 대한 할당 순서에 의해 결정된다. 할당은 아래의 커널 파라미터의 영향을 받을 수 있다.

To some degree SLUB’s performance is limited by the need to take the list_lock once in a while to deal with partial slabs. That overhead is governed by the order of the allocation for each slab. The allocations can be influenced by kernel parameters:

slub_min_objects=x (default 4)

slub_min_order=x (default 0)

slub_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER))

slub_min_objects 파라미터는 허용가능한 할당 순서를 위해 얼마나 많은 오브젝트가 최소한 하나의 슬랩에 들어가야 하는지를 지정할 수 있다. 일반적으로 슬럽은 발생할 수 있는 lock contention이 발생할 수 있는 list_lock을 사용하는 중앙 자원을 참조하지 않고 이런 류의 할당을 처리할 수 있다.

slub_min_objects allows to specify how many objects must at least fit into one slab in order for the allocation order to be acceptable. In general slub will be able to perform this number of allocations on a slab without consulting centralized resources (list_lock) where contention may occur.

slub_min_order 파라미터는 슬랩의 최소 order를 지정한다. slub_min_objects와 비슷한 효과를 나타낸다.

slub_min_order specifies a minim order of slabs. A similar effect like slub_min_objects.

slub_max_order 파라미터는 slub_min_objects 파라미터가 더이상 체크되지 않을 order를 나타낸다. 이는 슬럽이 큰 크기를 오브젝트를 가진 슬랩 캐시의 slub_min_objects 파라미터에 맞추기 위해 super large order pages를 생성하는 시도를 피할 수 있어서 유용하다. 커맨드라인 파라미터 debug_guardpage_minorder = N (N> 0)을 설정하면 slub_max_order를 0으로 설정하고 슬랩할당시에 사용한 최소한의 possible order를 결정한다.

slub_max_order specified the order at which slub_min_objects should no longer be checked. This is useful to avoid SLUB trying to generate super large order pages to fit slub_min_objects of a slab cache with large object sizes into one high order page. Setting command line parameter debug_guardpage_minorder=N (N > 0), forces setting slub_max_order to 0, what cause minimum possible order of slabs allocation.

슬럽 디버깅 결과(SLUB Debug output)

아래는 슬럽 디버그 출력 샘플이다.

Here is a sample of slub debug output:

====================================================================

BUG kmalloc-8: Redzone overwritten

--------------------------------------------------------------------

INFO: 0xc90f6d28-0xc90f6d2b. First byte 0x00 instead of 0xcc

INFO: Slab 0xc528c530 flags=0x400000c3 inuse=61 fp=0xc90f6d58

INFO: Object 0xc90f6d20 @offset=3360 fp=0xc90f6d58

INFO: Allocated in get_modalias+0x61/0xf5 age=53 cpu=1 pid=554

Bytes b4 0xc90f6d10: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ

 Object 0xc90f6d20: 31 30 31 39 2e 30 30 35 1019.005

 Redzone 0xc90f6d28: 00 cc cc cc .

 Padding 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ

[<c010523d>] dump_trace+0x63/0x1eb

 [<c01053df>] show_trace_log_lvl+0x1a/0x2f

 [<c010601d>] show_trace+0x12/0x14

 [<c0106035>] dump_stack+0x16/0x18

 [<c017e0fa>] object_err+0x143/0x14b

 [<c017e2cc>] check_object+0x66/0x234

 [<c017eb43>] __slab_free+0x239/0x384

 [<c017f446>] kfree+0xa6/0xc6

 [<c02e2335>] get_modalias+0xb9/0xf5

 [<c02e23b7>] dmi_dev_uevent+0x27/0x3c

 [<c027866a>] dev_uevent+0x1ad/0x1da

 [<c0205024>] kobject_uevent_env+0x20a/0x45b

 [<c020527f>] kobject_uevent+0xa/0xf

 [<c02779f1>] store_uevent+0x4f/0x58

 [<c027758e>] dev_attr_store+0x29/0x2f

 [<c01bec4f>] sysfs_write_file+0x16e/0x19c

 [<c0183ba7>] vfs_write+0xd1/0x15a

 [<c01841d7>] sys_write+0x3d/0x72

 [<c0104112>] sysenter_past_esp+0x5f/0x99

 [<b7f7b410>] 0xb7f7b410

 =======================

FIX kmalloc-8: Restoring Redzone 0xc90f6d28-0xc90f6d2b=0xcc

SLUB에 오염된 오브젝트가 발생하면(전체 탐지를 위해서는 slub_debug 파라미터를 사용해서 커널을 부팅해야 함) 다음 내용이 syslog에 출력된다.

If SLUB encounters a corrupted object (full detection requires the kernel to be booted with slub_debug) then the following output will be dumped into the syslog:

1.발생한 문제에 대한 설명(Description of the problem encountered) 

아래 메세지는 시스템 로그의 시작부분에 출력된다.

This will be a message in the system log starting with

===============================================

BUG <slab cache affected>: <What went wrong>

-----------------------------------------------

INFO: <corruption start>-<corruption_end> <more info>

INFO: Slab <address> <slab information>

INFO: Object <address> <object information>

INFO: Allocated in <kernel function> age=<jiffies since alloc> cpu=<allocated by

 cpu> pid=<pid of the process>

INFO: Freed in <kernel function> age=<jiffies since free> cpu=<freed by cpu>

 pid=<pid of the process>

(오브젝트 할당/해제 정보는 슬랩에 SLAB_STORE_USER가 설정된 경우에만 사용할 수 있으며 slub_debug 파라미터에서 해당 옵션(U)을 설정할 수 있다.)

(Object allocation / free information is only available if SLAB_STORE_USER is set for the slab. slub_debug sets that option)

2.슬랩 오브젝트의 내용(오브젝트가 관련된 경우) The object contents if an object was involved.

다양한 유형의 행이 BUG SLUB 행 결과가 뒤따라 출력될 수 있다.

Various types of lines can follow the BUG SLUB line:

Bytes b4 <address> : <bytes>

문제가 발견 된 오브젝트 앞 몇 바이트를 출력한다. corruption이 오브젝트의 시작주소 전에 멈추지 않는다면 유용 할 수 있다.

Shows a few bytes before the object where the problem was detected. Can be useful if the corruption does not stop with the start of the object.

Object <address> : <bytes>

오브젝트의 바이트단위 크기를 나타냄. 오브젝트가 비활성 상태이면 바이트는 일반적으로 포이즌 영역의 크기를 포함한다. poison 영역에 쓰이지 않는 값이 슬랩 해제 후에 쓰여진 corruption을 나타낸다.

The bytes of the object. If the object is inactive then the bytes typically contain poison values. Any non-poison value shows a corruption by a write after free.

Redzone <address> : <bytes>

슬랩 오브젝트 뒤에 위치하는 레드존을 나타낸다. 레드존은 오브젝트 영역 다음 영역에 대한 쓰기를 감지하는데 사용된다. 레드존의 모든 바이트는 항상 같은 값을 가져야한다. 문제가 있는 경우 오브젝트 경계 다음(레드존)에 쓰기가 발생한다.

The Redzone following the object. The Redzone is used to detect writes after the object. All bytes should always have the same value. If there is any deviation then it is due to a write after the object boundary.

(Redzone 정보는 SLAB_RED_ZONE이 설정된 경우에만 사용할 수 있으며 slub_debug에서 이 옵션(Z)을 설정할 수 있다.)

(Redzone information is only available if SLAB_RED_ZONE is set. slub_debug sets that option)

Padding <address> : <bytes>

사용되지 않은 데이터로 공간을 채워서 다음 오브젝트를 올바르게 정렬시킨다. 디버깅의 경우 적어도 4 바이트의 패딩이 있는지 확인한다. 이렇게 하면 슬랩 오브젝트를 넘어선 쓰기를 탐지 할 수 있다.

Unused data to fill up the space in order to get the next object properly aligned. In the debug case we make sure that there are at least 4 bytes of padding. This allows the detection of writes before the object.

3.스택 덤프(A stackdump) 

스택 덤프는 에러가 발견된 함수 위치를 나타낸다. 오염을 일으킨 원인은 오브젝트를 할당하거나 해제 한 함수를 살펴보면 더 쉽게 발견 될 수 있다.

The stackdump describes the location where the error was detected. The cause of the corruption is may be more likely found by looking at the function that allocated or freed the object.

4.시스템의 지속적인 작동을 보장하기 위해 문제가 어떻게 처리되었는지에 대한 출력(Report on how the problem was dealt with in order to ensure the continued operation of the system.)

이 로그들은 아래와 같은 로그와 함께 출력된다.

These are messages in the system log beginning with

FIX <slab cache affected>: <corrective action taken>

위 샘플에서 SLUB은 활성 오브젝트의 레드존이 덮어쓰기 된것을 발견했다. 8 자 길이의 슬랩에 8 자의 문자열이 기록되었다. 그러나 8 자 문자열은 0으로 종료되어야 한다. 0은 레드존의 첫 번째 바이트를 덮어 쓴다. 문제의 세부 사항을 출력한 후 FIX SLUB 메시지는 SLUB이 레드존을 적절한 값으로 복원 한 다음 시스템 작동이 계속된다는 것을 알려준다.

In the above sample SLUB found that the Redzone of an active object has been overwritten. Here a string of 8 characters was written into a slab that has the length of 8 characters. However, a 8 character string needs a terminating 0. That zero has overwritten the first byte of the Redzone field. After reporting the details of the issue encountered the FIX SLUB message tells us that SLUB has restored the Redzone to its proper value and then system operations continue.

비상시의 동작(Emergency operations)

부팅시 최소한의 디버깅만(sanity 체크)을 활성화 할 수 있다.

Minimal debugging (sanity checks alone) can be enabled by booting with

slub_debug=F

일반적으로 이 설정은 만약 잘못된 커널 코드에 의해 corrupting 오브젝트가 유지되더라도 시스템이 계속 동작하게 해주는 slub의 복원기능을 활성화하는데 충분하다.이는 프로덕션 시스템에서 중요 할 수 있다. 성능은 sanity 검사의 영향을 받을 것이고 syslog에 오류 메시지가 계속해서 발생하지만 전체 디버깅과 달리 추가 메모리는 사용되지 않는다.

This will be generally be enough to enable the resiliency features of slub which will keep the system running even if a bad kernel component will keep corrupting objects. This may be important for production systems. Performance will be impacted by the sanity checks and there will be a continual stream of error messages to the syslog but no additional memory will be used (unlike full debugging).

보장되는 것은 없다. 잘못된 커널 코드는 여전히 수정해야 한다. 오염된 적이 있던 슬랩을 찾고 해당 캐시에 대해서만 디버깅을 활성화하여 성능을 더욱 최적화 할 수 있다.

No guarantees. The kernel component still needs to be fixed. Performance may be optimized further by locating the slab that experiences corruption and enabling debugging only for that cache

예를 들어(I.e),

 slub_debug=F,dentry

오브젝트의 영역을 벗어난 곳에 대한 쓰기접근에 의해 오염이 발생하면 다른 오브젝트의 시작 부분이 오염되지 않도록 레드존을 활성화하는 것이 좋다.

If the corruption occurs by writing after the end of the object then it may be advisable to enable a Redzone to avoid corrupting the beginning of other objects.

slub_debug=FZ,dentry

slabinfo의 확장모드와 플로팅(Extended slabinfo mode and plotting)

slabinfo 툴은 아래를 포함한 특별한 extended mode를 지원한다.

The slabinfo tool has a special ‘extended’ (‘-X’) mode that includes:

총 슬랩캐시(Slabcache Totals)

사이즈로 정렬한 슬랩리스트(Slabs sorted by size (up to -N <num> slabs, default 1))

loss를 기준으로 정렬할 슬랩리스트(Slabs sorted by loss (up to -N <num> slabs, default 1))

또한 이 모드에서 slabinfo는 동적으로 크기(G/M/K)를 조정하지 않고 모든 것을 바이트 단위로 보고한다(이 기능은 ‘-B’옵션을 통해 다른 slabinfo 모드에서도 사용할 수 있음). 이 것은 출력 내용을 더욱 더 정밀하고 정확하게 만들어준다. 또한 어떤 의미에서 ‘-X’ 모드는 slabinfo-gnuplot.sh 스크립트를 사용하여 출력을 plot 할 수 있기 때문에 슬랩의 동작 분석을 단순하게 한다. 따라서 숫자(많은)를 통해 분석하는 것에서 좀 더 쉬운 시각적은 분석을 하게 한다.

Additionally, in this mode slabinfo does not dynamically scale sizes (G/M/K) and reports everything in bytes (this functionality is also available to other slabinfo modes via ‘-B’ option) which makes reporting more precise and accurate. Moreover, in some sense the `-X’ mode also simplifies the analysis of slabs’ behaviour, because its output can be plotted using the slabinfo-gnuplot.sh script. So it pushes the analysis from looking through the numbers (tons of numbers) to something easier — visual analysis.

plot을 만들기 위해서는(To generate plots):

a) sliabinfo의 extended record를 수집한다, 예를 들면 아래와 같다.(collect slabinfo extended records, for example)

while [ 1 ]; do slabinfo -X >> FOO_STATS; sleep 1; done

b) stats 파일을 slabinfo-gnuplot.sh 스크립트에 전달한다(pass stats file(-s) to slabinfo-gnuplot.sh script)

slabinfo-gnuplot.sh FOO_STATS [FOO_STATS2 .. FOO_STATSN]

slabinfo-gnuplot.sh 스크립트는 수집 된 레코드를 사전 처리하고 STATS 파일 당 아래 3 개 png 파일 (3 개의 사전 처리 캐시 파일)을 생성한다.

The slabinfo-gnuplot.sh script will pre-processes the collected records and generates 3 png files (and 3 pre-processing cache files) per STATS file:

Slabcache Totals: FOO_STATS-totals.png

Slabs sorted by size: FOO_STATS-slabs-by-size.png

Slabs sorted by loss: FOO_STATS-slabs-by-loss.png

slabinfo-gnuplot 스크릅트가 유용 할 수있는 또 다른 사용 사례는 일부 코드수정에 대한 슬랩 동작을 “이전”과 “후”로 비교해야 할 때이다. 거기서 당신을 도울 수 있도록 slabinfo-gnuplot.sh 스크립트는 다른 측정의 Slabcache Totals 섹션을 ‘병합’할 수 있다. 시각적으로 N 개의 그림을 비교하려면

Another use case, when slabinfo-gnuplot can be useful, is when you need to compare slabs’ behaviour “prior to” and “after” some code modification. To help you out there, slabinfo-gnuplot.sh script can ‘merge’ the `Slabcache Totals` sections from different measurements. To visually compare N plots:

a) 필요한만큼 STATS1, STATS2, .. STATSN 파일을 수집하기

a) Collect as many STATS1, STATS2, .. STATSN files as you need

while [ 1 ]; do slabinfo -X >> STATS<X>; sleep 1; done

b) 해당 STATS 파일을 사전 처리하기

b) Pre-process those STATS files

slabinfo-gnuplot.sh STATS1 STATS2 .. STATSN

c) ‘-t’모드에서 slabinfo-gnuplot.sh를 실행하여 생성 된 모든 전처리 된 *-totals를 전달

c) Execute slabinfo-gnuplot.sh in ‘-t’ mode, passing all of the generated pre-processed *-totals

slabinfo-gnuplot.sh -t STATS1-totals STATS2-totals .. STATSN-totals

이 절차는 단일 플롯(png 파일)을 생성한다.

This will produce a single plot (png file).

플롯은 커질 수 있으므로 약간의 변동이나 작은 스파이크가 눈에 띄지 않을 수 있다. 이를 처리하기 위해 slabinfo-gnuplot.sh 스크립트에는 ‘zoom-in’/’zoom-out’ 두 가지 옵션이 있다 :

Plots, expectedly, can be large so some fluctuations or small spikes can go unnoticed. To deal with that, `slabinfo-gnuplot.sh’ has two options to ‘zoom-in’/’zoom-out’:

a) -s %d,%d 는 기본 이미지 너비와 높이를 덮어쓴다.

a) -s %d,%d overwrites the default image width and heigh

b) -r %d,%d 는 사용할 샘플의 범위를 명시한다(예를 들어, slabinfo -X >> FOOT_STATS; sleep 1; case에서 “-r 40,60” 을 사용하면 40번초~60초 사이에 수집된 샘플만 플롯된다.

b) -r %d,%d specifies a range of samples to use (for example, in `slabinfo -X >> FOO_STATS; sleep 1;’ case, using a “-r 40,60” range will plot only samples collected between 40th and 60th seconds).

Christoph Lameter, May 30, 2007

Sergey Senozhatsky, October 23, 2015