diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/filesystems/proc.txt | 6 | ||||
-rw-r--r-- | Documentation/networking/packet_mmap.txt | 10 |
2 files changed, 8 insertions, 8 deletions
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 944cf109a6f5..99902ae6804e 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -121,7 +121,7 @@ Table 1-1: Process specific entries in /proc | |||
121 | .............................................................................. | 121 | .............................................................................. |
122 | File Content | 122 | File Content |
123 | cmdline Command line arguments | 123 | cmdline Command line arguments |
124 | cpu Current and last cpu in wich it was executed (2.4)(smp) | 124 | cpu Current and last cpu in which it was executed (2.4)(smp) |
125 | cwd Link to the current working directory | 125 | cwd Link to the current working directory |
126 | environ Values of environment variables | 126 | environ Values of environment variables |
127 | exe Link to the executable of this process | 127 | exe Link to the executable of this process |
@@ -309,13 +309,13 @@ is the same by default: | |||
309 | > cat /proc/irq/0/smp_affinity | 309 | > cat /proc/irq/0/smp_affinity |
310 | ffffffff | 310 | ffffffff |
311 | 311 | ||
312 | It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can | 312 | It's a bitmask, in which you can specify which CPUs can handle the IRQ, you can |
313 | set it by doing: | 313 | set it by doing: |
314 | 314 | ||
315 | > echo 1 > /proc/irq/prof_cpu_mask | 315 | > echo 1 > /proc/irq/prof_cpu_mask |
316 | 316 | ||
317 | This means that only the first CPU will handle the IRQ, but you can also echo 5 | 317 | This means that only the first CPU will handle the IRQ, but you can also echo 5 |
318 | wich means that only the first and fourth CPU can handle the IRQ. | 318 | which means that only the first and fourth CPU can handle the IRQ. |
319 | 319 | ||
320 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin | 320 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin |
321 | between all the CPUs which are allowed to handle it. As usual the kernel has | 321 | between all the CPUs which are allowed to handle it. As usual the kernel has |
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 8d4cf78258e4..4fc8e9874320 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt | |||
@@ -40,7 +40,7 @@ network interface card supports some sort of interrupt load mitigation or | |||
40 | + How to use CONFIG_PACKET_MMAP | 40 | + How to use CONFIG_PACKET_MMAP |
41 | -------------------------------------------------------------------------------- | 41 | -------------------------------------------------------------------------------- |
42 | 42 | ||
43 | From the user standpoint, you should use the higher level libpcap library, wich | 43 | From the user standpoint, you should use the higher level libpcap library, which |
44 | is a de facto standard, portable across nearly all operating systems | 44 | is a de facto standard, portable across nearly all operating systems |
45 | including Win32. | 45 | including Win32. |
46 | 46 | ||
@@ -217,8 +217,8 @@ called pg_vec, its size limits the number of blocks that can be allocated. | |||
217 | 217 | ||
218 | kmalloc allocates any number of bytes of phisically contiguous memory from | 218 | kmalloc allocates any number of bytes of phisically contiguous memory from |
219 | a pool of pre-determined sizes. This pool of memory is mantained by the slab | 219 | a pool of pre-determined sizes. This pool of memory is mantained by the slab |
220 | allocator wich is at the end the responsible for doing the allocation and | 220 | allocator which is at the end the responsible for doing the allocation and |
221 | hence wich imposes the maximum memory that kmalloc can allocate. | 221 | hence which imposes the maximum memory that kmalloc can allocate. |
222 | 222 | ||
223 | In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The | 223 | In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The |
224 | predetermined sizes that kmalloc uses can be checked in the "size-<bytes>" | 224 | predetermined sizes that kmalloc uses can be checked in the "size-<bytes>" |
@@ -254,7 +254,7 @@ and, the number of frames be | |||
254 | 254 | ||
255 | <block number> * <block size> / <frame size> | 255 | <block number> * <block size> / <frame size> |
256 | 256 | ||
257 | Suposse the following parameters, wich apply for 2.6 kernel and an | 257 | Suposse the following parameters, which apply for 2.6 kernel and an |
258 | i386 architecture: | 258 | i386 architecture: |
259 | 259 | ||
260 | <size-max> = 131072 bytes | 260 | <size-max> = 131072 bytes |
@@ -360,7 +360,7 @@ TP_STATUS_LOSING : indicates there were packet drops from last time | |||
360 | statistics where checked with getsockopt() and | 360 | statistics where checked with getsockopt() and |
361 | the PACKET_STATISTICS option. | 361 | the PACKET_STATISTICS option. |
362 | 362 | ||
363 | TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets wich | 363 | TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which |
364 | it's checksum will be done in hardware. So while | 364 | it's checksum will be done in hardware. So while |
365 | reading the packet we should not try to check the | 365 | reading the packet we should not try to check the |
366 | checksum. | 366 | checksum. |