| /linux/Documentation/netlink/specs/ |
| H A D | dev-energymodel.yaml | 21 name: perf-state-inefficient
23 The performance state is inefficient. There is in this perf-domain,
37 Skip inefficient states when estimating energy consumption.
|
| /linux/include/uapi/linux/ |
| H A D | dev_energymodel.h | 16 * state is inefficient. There is in this perf-domain, another performance
28 * inefficient states when estimating energy consumption.
|
| /linux/include/linux/ |
| H A D | energy_model.h | 35 * EM_PERF_STATE_INEFFICIENT: The performance state is inefficient. There is
37 * but a lower or equal power cost. Such inefficient states are ignored when
91 * EM_PERF_DOMAIN_SKIP_INEFFICIENCIES: Skip inefficient states when estimating
|
| /linux/Documentation/filesystems/ext4/ |
| H A D | inlinedata.rst | 20 that, the limit was 156 bytes due to inefficient use of inode space.
|
| /linux/arch/xtensa/lib/ |
| H A D | checksum.S | 279 inefficient, so align your addresses to 4-byte boundaries.
318 process all bytes using 8-bit accesses. Grossly inefficient,
|
| /linux/lib/crc/x86/ |
| H A D | crc32.h | 85 * combination would be inefficient here. in crc32c_arch()
|
| /linux/fs/fuse/ |
| H A D | backing.c | 46 /* FIXME: xarray might be space inefficient */ in fuse_backing_id_alloc()
|
| /linux/drivers/mtd/chips/ |
| H A D | map_ram.c | 130 /* Yeah, it's inefficient. Who cares? It's faster than a _real_ in mapram_erase()
|
| /linux/Documentation/filesystems/iomap/ |
| H A D | porting.rst | 28 as ext2, but is very inefficient for extent-based filesystems such
|
| /linux/kernel/power/ |
| H A D | energy_model.c | 109 debugfs_create_file("inefficient", 0444, d, &em_dbg[i], in em_debug_create_ps()
285 dev_dbg(dev, "EM: OPP:%lu is inefficient\n", in em_compute_costs()
524 * Efficiencies have been installed in CPUFreq, inefficient frequencies in em_cpufreq_update_efficiencies()
|
| /linux/Documentation/mm/ |
| H A D | hwpoison.rst | 35 Some of the operations here are somewhat inefficient and have non
|
| /linux/fs/cramfs/ |
| H A D | README | 175 Option 3 is easy to implement if we don't mind being CPU-inefficient:
|
| /linux/arch/powerpc/sysdev/ |
| H A D | mpic_msgr.c | 104 * the message register blocks. They are clearly very inefficient. However,
|
| /linux/Documentation/filesystems/ |
| H A D | fiemap.rst | 158 userspace would be highly inefficient, the kernel will try to merge most
|
| /linux/Documentation/accounting/ |
| H A D | taskstats.rst | 123 stats in userspace alone is inefficient and potentially inaccurate (due to lack
|
| /linux/Documentation/userspace-api/media/mediactl/ |
| H A D | request-api.rst | 20 it is, it is terribly inefficient: user-space would have to flush all activity
|
| /linux/arch/arm/lib/ |
| H A D | csumpartialcopygeneric.S | 156 * the inefficient byte manipulations in the
|
| /linux/drivers/md/ |
| H A D | dm-log.c | 615 /* FIXME: amazingly inefficient */ in disk_resume()
619 /* FIXME: amazingly inefficient */ in disk_resume()
|
| /linux/lib/zlib_dfltcc/ |
| H A D | dfltcc_deflate.c | 258 * inefficient. Since there is masked data, there will be at least in dfltcc_deflate()
|
| /linux/Documentation/filesystems/spufs/ |
| H A D | spufs.rst | 159 npc requires an SPU context save and is therefore very inefficient.
|
| /linux/lib/math/ |
| H A D | div64.c | 15 * Code generated for this function might be very inefficient
|
| /linux/drivers/usb/mon/ |
| H A D | mon_main.c | 320 * This is obviously inefficient and may be revised in the future.
|
| /linux/drivers/gpu/drm/i915/ |
| H A D | i915_vma_resource.c | 143 /* Inefficient open-coded might_lock_irqsave() */ in i915_vma_resource_unhold()
|
| /linux/arch/sh/mm/ |
| H A D | cache-sh4.c | 58 * This is inefficient, so only use this for small ranges. in sh4_flush_icache_range()
|
| /linux/drivers/md/bcache/ |
| H A D | bcache.h | 118 * Anyways, btree nodes are big - big enough to be inefficient with a textbook
165 * a few keys each) - highly inefficient in terms of amount of metadata writes,
|