# # IrDA protocol configuration # menuconfig IRDA depends on NET && !S390 tristate "IrDA (infrared) subsystem support" select CRC_CCITT ---help--- Say Y here if you want to build support for the IrDA (TM) protocols. The Infrared Data Associations (tm) specifies standards for wireless infrared communication and is supported by most laptops and PDA's. To use Linux support for the IrDA (tm) protocols, you will also need some user-space utilities like irattach. For more information, see the file . You also want to read the IR-HOWTO, available at . If you want to exchange bits of data (vCal, vCard) with a PDA, you will need to install some OBEX application, such as OpenObex : To compile this support as a module, choose M here: the module will be called irda. comment "IrDA protocols" depends on IRDA source "net/irda/irlan/Kconfig" source "net/irda/irnet/Kconfig" source "net/irda/ircomm/Kconfig" config IRDA_ULTRA bool "Ultra (connectionless) protocol" depends on IRDA help Say Y here to support the connectionless Ultra IRDA protocol. Ultra allows to exchange data over IrDA with really simple devices (watch, beacon) without the overhead of the IrDA protocol (no handshaking, no management frames, simple fixed header). Ultra is available as a special socket : socket(AF_IRDA, SOCK_DGRAM, 1); comment "IrDA options" depends on IRDA config IRDA_CACHE_LAST_LSAP bool "Cache last LSAP" depends on IRDA help Say Y here if you want IrLMP to cache the last LSAP used. This makes sense since most frames will be sent/received on the same connection. Enabling this option will save a hash-lookup per frame. If unsure, say Y. config IRDA_FAST_RR bool "Fast RRs (low latency)" depends on IRDA ---help--- Say Y here is you want IrLAP to send fast RR (Receive Ready) frames when acting as a primary station. Disabling this option will make latency over IrDA very bad. Enabling this option will make the IrDA stack send more packet than strictly necessary, thus reduce your battery life (but not that much). Fast RR will make IrLAP send out a RR frame immediately when receiving a frame if its own transmit queue is currently empty. This will give a lot of speed improvement when receiving much data since the secondary station will not have to wait the max. turn around time (usually 500ms) before it is allowed to transmit the next time. If the transmit queue of the secondary is also empty, the primary will start backing-off before sending another RR frame, waiting longer each time until the back-off reaches the max. turn around time. This back-off increase in controlled via /proc/sys/net/irda/fast_poll_increase If unsure, say Y. config IRDA_DEBUG bool "Debug information" depends on IRDA help Say Y here if you want the IrDA subsystem to write debug information to your syslog. You can change the debug level in /proc/sys/net/irda/debug . When this option is enabled, the IrDA also perform many extra internal verifications which will usually prevent the kernel to crash in case of bugs. If unsure, say Y (since it makes it easier to find the bugs). source "drivers/net/irda/Kconfig" me='ignorews' onchange='this.form.submit();'>mode:
authorDmitry Vyukov <dvyukov@google.com>2016-12-12 16:44:56 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2016-12-12 18:55:09 -0800
commit64abdcb24351a27bed6e2b6a3c27348fe532c73f (patch)
treec92a58fadc84a336877a1f902dd7eb13152c70cf
parent5c5c1f36cedfb51ec291181e71817f7fe7e03ee2 (diff)
kasan: eliminate long stalls during quarantine reduction
Currently we dedicate 1/32 of RAM for quarantine and then reduce it by 1/4 of total quarantine size. This can be a significant amount of memory. For example, with 4GB of RAM total quarantine size is 128MB and it is reduced by 32MB at a time. With 128GB of RAM total quarantine size is 4GB and it is reduced by 1GB. This leads to several problems: - freeing 1GB can take tens of seconds, causes rcu stall warnings and just introduces unexpected long delays at random places - if kmalloc() is called under a mutex, other threads stall on that mutex while a thread reduces quarantine - threads wait on quarantine_lock while one thread grabs a large batch of objects to evict - we walk the uncached list of object to free twice which makes all of the above worse - when a thread frees objects, they are already not accounted against global_quarantine.bytes; as the result we can have quarantine_size bytes in quarantine + unbounded amount of memory in large batches in threads that are in process of freeing Reduce size of quarantine in smaller batches to reduce the delays. The only reason to reduce it in batches is amortization of overheads, the new batch size of 1MB should be well enough to amortize spinlock lock/unlock and few function calls. Plus organize quarantine as a FIFO array of batches. This allows to not walk the list in quarantine_reduce() under quarantine_lock, which in turn reduces contention and is just faster. This improves performance of heavy load (syzkaller fuzzing) by ~20% with 4 CPUs and 32GB of RAM. Also this eliminates frequent (every 5 sec) drops of CPU consumption from ~400% to ~100% (one thread reduces quarantine while others are waiting on a mutex). Some reference numbers: 1. Machine with 4 CPUs and 4GB of memory. Quarantine size 128MB. Currently we free 32MB at at time. With new code we free 1MB at a time (1024 batches, ~128 are used). 2. Machine with 32 CPUs and 128GB of memory. Quarantine size 4GB. Currently we free 1GB at at time. With new code we free 8MB at a time (1024 batches, ~512 are used). 3. Machine with 4096 CPUs and 1TB of memory. Quarantine size 32GB. Currently we free 8GB at at time. With new code we free 4MB at a time (16K batches, ~8K are used). Link: http://lkml.kernel.org/r/1478756952-18695-1-git-send-email-dvyukov@google.com Signed-off-by: Dmitry Vyukov <dvyukov@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Greg Thelen <gthelen@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat