Home
last modified time | relevance | path

Searched full:inefficient (Results 1 – 25 of 128) sorted by relevance

123456

/linux/Documentation/netlink/specs/
H A Ddev-energymodel.yaml21 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 Ddev_energymodel.h16 * state is inefficient. There is in this perf-domain, another performance
28 * inefficient states when estimating energy consumption.
/linux/include/linux/
H A Denergy_model.h35 * 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
H A Dcpufreq.h120 * Set if inefficient frequencies were found in the frequency table.
1119 * cpufreq_table_set_inefficient() - Mark a frequency as inefficient
1120 * @policy: the &struct cpufreq_policy containing the inefficient frequency
1121 * @frequency: the inefficient frequency
/linux/Documentation/filesystems/ext4/
H A Dinlinedata.rst20 that, the limit was 156 bytes due to inefficient use of inode space.
/linux/arch/xtensa/lib/
H A Dchecksum.S279 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 Dcrc32.h85 * combination would be inefficient here. in crc32c_arch()
/linux/fs/fuse/
H A Dbacking.c46 /* FIXME: xarray might be space inefficient */ in fuse_backing_id_alloc()
/linux/lib/crypto/tests/
H A Dmldsa_kunit.c335 /* Mechanical, inefficient translation of FIPS 204 Algorithm 36, Decompose */
349 /* Mechanical, inefficient translation of FIPS 204 Algorithm 40, UseHint */
/linux/drivers/mtd/chips/
H A Dmap_ram.c130 /* Yeah, it's inefficient. Who cares? It's faster than a _real_ in mapram_erase()
/linux/Documentation/filesystems/iomap/
H A Dporting.rst28 as ext2, but is very inefficient for extent-based filesystems such
/linux/kernel/power/
H A Denergy_model.c109 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 Dhwpoison.rst35 Some of the operations here are somewhat inefficient and have non
/linux/Documentation/filesystems/
H A Dpath-lookup.txt27 next path element. This is inefficient and unscalable. It is inefficient
H A Dfiemap.rst158 userspace would be highly inefficient, the kernel will try to merge most
H A Dfsverity.rst50 this is inefficient if the file is large and only a small portion may
817 first read. However, it would be inefficient because every time a
857 extremely inefficient. Alternatively, a different authenticated
/linux/fs/cramfs/
H A DREADME175 Option 3 is easy to implement if we don't mind being CPU-inefficient:
/linux/Documentation/networking/
H A Dstatistics.rst140 environments without access to tools. However, it's inefficient when
/linux/arch/powerpc/sysdev/
H A Dmpic_msgr.c104 * the message register blocks. They are clearly very inefficient. However,
/linux/Documentation/accounting/
H A Dtaskstats.rst123 stats in userspace alone is inefficient and potentially inaccurate (due to lack
/linux/arch/arm/lib/
H A Dcsumpartialcopygeneric.S156 * the inefficient byte manipulations in the
/linux/Documentation/userspace-api/media/mediactl/
H A Drequest-api.rst20 it is, it is terribly inefficient: user-space would have to flush all activity
/linux/drivers/md/
H A Ddm-log.c615 /* FIXME: amazingly inefficient */ in disk_resume()
619 /* FIXME: amazingly inefficient */ in disk_resume()
/linux/lib/zlib_dfltcc/
H A Ddfltcc_deflate.c258 * inefficient. Since there is masked data, there will be at least in dfltcc_deflate()
/linux/Documentation/filesystems/spufs/
H A Dspufs.rst159 npc requires an SPU context save and is therefore very inefficient.

123456