Home
last modified time | relevance | path

Searched full:much (Results 1 – 25 of 1902) sorted by relevance

12345678910>>...77

/linux/drivers/media/pci/bt8xx/
H A Dbttv-audio-hook.c60 /* Not much to do here */ in gvbctv3pci_audio()
162 /* Not much to do here */ in avermedia_tvphone_audio()
193 /* Not much to do here */ in avermedia_tv_stereo_audio()
231 /* Not much to do here */ in lt9415_audio()
264 /* Not much to do here */ in terratv_audio()
336 /* Not much to do here */ in pvbt878p9b_audio()
377 /* Not much to do here */ in fv2000s_audio()
413 /* Not much to do here */ in windvr_audio()
450 /* Not much to do here */ in adtvk503_audio()
/linux/Documentation/arch/x86/
H A Dorc-unwinder.rst12 format of the ORC data is much simpler than DWARF, which in turn allows
13 the ORC unwinder to be much simpler and faster.
63 ORC debuginfo's advantage over DWARF itself is that it's much simpler.
66 much simpler, meaning fewer bugs, which is especially important for
69 The simpler debuginfo format also enables the unwinder to be much faster
114 annotations are needed than what DWARF would need, so they're much more
/linux/Documentation/process/
H A Dbotching-up-ioctls.rst14 actually only used once interfaces. But the clear downside is that there's much
110 paths pretty much for free for graphics drivers. Also, be consistent with
160 an asynchronous event on a pollable file descriptor. It fits much better
208 it's much quicker to push a driver-private interface than engaging in
214 * Consider other interfaces than ioctls. A sysfs attribute is much better for
/linux/Documentation/scheduler/
H A Dsched-nice-design.rst9 pestered us to make nice +19 tasks use up much less CPU time.
17 much stronger than they were before in 2.4 (and people were happy about
39 So that if someone wanted to really renice tasks, +19 would give a much
/linux/Documentation/arch/powerpc/
H A Dkasan.txt48 this at run-time based on how much physical memory we have, but this requires
54 requires knowing how much contiguous physical memory a system has _at compile
/linux/net/batman-adv/
H A Dbitarray.c60 /* sequence number is much newer, probably missed a lot of packets */ in batadv_bit_get_packet()
72 /* received a much older packet. The other host either restarted in batadv_bit_get_packet()
/linux/drivers/tty/
H A Dehv_bytechan.c358 /* Find out how much data needs to be read, and then ask the TTY layer in ehv_bc_tty_rx_isr()
359 * if it can handle that much. We want to ensure that every byte we in ehv_bc_tty_rx_isr()
407 * This function, which can be called in interrupt context, dequeues as much
463 * the data first in a circular buffer, and then dequeue as much of that data
468 * layer how much data it can safely send to us. We guarantee that
470 * too much data.
538 * how much write room the driver can guarantee will be sent OR BUFFERED. This
601 * If we could ask the hypervisor how much data is still in the TX buffer, or
/linux/Documentation/driver-api/driver-model/
H A Ddevres.rst15 5. Overhead : How much do we have to pay for this?
35 For one reason or another, low level drivers don't receive as much
38 Init failure path is worse because it's much less travelled while
102 driver can have much simpler init and exit code. Init path basically
/linux/include/uapi/linux/
H A Dresource.h76 * The first two don't need much. The latter will take as
77 * much as it can get. 8MB is a reasonably sane default.
/linux/arch/arm64/kernel/
H A Dwatchdog_hld.c10 * Arm CPUs in the market which are clocked much less than 5 GHz. On the other
11 * hand, we can't make it much higher as it would lead to a large hard-lockup
/linux/arch/arm/include/asm/
H A Dkgdb.h34 * make our lives much much simpler. :)
/linux/Documentation/misc-devices/
H A Dapds990x.rst26 might vary quite much depending the spectrum of the light source.
68 to saturate much before that. Real max value varies depending
/linux/drivers/block/drbd/
H A Ddrbd_vli.h20 * the bitmap transfer time can take much too long,
37 * integers would be much worse than plaintext.
48 * We don't care too much about "excellent" compression ratio for large
50 * or 1000 is not that much of an issue.
51 * We do not want to waste too much on short runlengths in the "noisy"
/linux/include/linux/
H A Dstringhash.h18 * malicious inputs; much slower hash functions are required for that.
62 * this computes a different hash function much faster.
H A Dnfs_iostat.h48 * traffic. NORMAL + DIRECT shows how much data is going through
50 * without much NORMAL or DIRECT traffic shows that applications
H A Dzstd.h497 * @output: Destination buffer. `output->pos` is updated to indicate how much
499 * @input: Source buffer. `input->pos` is updated to indicate how much data
517 * @output: Destination buffer. `output->pos` is updated to indicate how much
532 * @output: Destination buffer. `output->pos` is updated to indicate how much
584 * @output: Destination buffer. `output.pos` is updated to indicate how much
586 * @input: Source buffer. `input.pos` is updated to indicate how much data was
/linux/Documentation/admin-guide/pm/
H A Dstrategies.rst42 then it takes much less time and effort to start executing user space code than
45 typically the system can spend much more time in a sleep state than it can be
/linux/lib/zstd/common/
H A Derror_private.c30 … case PREFIX(frameParameter_windowTooLarge): return "Frame requires too much memory for decoding"; in ERR_getErrorString()
41 case PREFIX(tableLog_tooLarge): return "tableLog requires too much memory : unsupported"; in ERR_getErrorString()
/linux/arch/alpha/lib/
H A Dev67-strchr.S9 * Much of the information about 21264 scheduling/coding comes from:
65 * data to be loaded. Not much can be done about it unless it's
/linux/fs/jffs2/
H A Dcompr_rtime.c69 /* Tell the caller how much we managed to compress, and how much space it took */ in jffs2_rtime_compress()
/linux/Documentation/driver-api/surface_aggregator/
H A Doverview.rst17 Not much is currently known about SAM on 4th generation devices (Surface Pro
32 While features have not changed much on a coarse level since the 5th
/linux/fs/btrfs/
H A Dspace-info.c28 * 1) space_info. This is the ultimate arbiter of how much space we can use.
38 * much space is accounted for in space_info->bytes_may_use.
119 * Look at the delalloc comment to get an idea of how much space is reserved
462 * overcommit much, and if we're very close to full it'll keep us from in calc_available_free_space()
473 * too much, let it overcommit up to 1/8 of the space. in calc_available_free_space()
484 * will over-commit too much leading to ENOSPC. Align down to the in calc_available_free_space()
695 * to_reclaim is set to however much metadata we need to in shrink_delalloc()
696 * reclaim, but reclaiming that much data doesn't really track in shrink_delalloc()
992 * much delalloc we need for the background flusher to kick in. in need_preemptive_reclaim()
1215 * This is for normal flushers, it can wait as much time as needed. We will
[all …]
/linux/fs/freevxfs/
H A Dvxfs_inode.h104 __fs32 vdi_blocks; /* How much blocks does inode occupy */
148 __u32 vii_blocks; /* How much blocks does inode occupy */
/linux/arch/sparc/include/asm/
H A Dswitch_to_32.h47 /* Much care has gone into this code, do not touch it.
55 * Hey Dave, that do not touch sign is too much of an incentive
/linux/Documentation/RCU/
H A Drcu_dereference.rst41 the section entitled "EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH"
52 The compiler simply knows too much about integral values to
66 doing much of anything else with it.
200 will normally prevent the compiler from knowing too much.
341 EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH

12345678910>>...77