Home
last modified time | relevance | path

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

12345

/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.
1114 * cpufreq_table_set_inefficient() - Mark a frequency as inefficient
1115 * @policy: the &struct cpufreq_policy containing the inefficient frequency
1116 * @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/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/Documentation/mm/
H A Dhwpoison.rst35 Some of the operations here are somewhat inefficient and have non
/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/fs/cramfs/
H A DREADME175 Option 3 is easy to implement if we don't mind being CPU-inefficient:
/linux/arch/powerpc/sysdev/
H A Dmpic_msgr.c104 * the message register blocks. They are clearly very inefficient. However,
/linux/Documentation/filesystems/
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
801 first read. However, it would be inefficient because every time a
841 extremely inefficient. Alternatively, a different authenticated
/linux/Documentation/accounting/
H A Dtaskstats.rst123 stats in userspace alone is inefficient and potentially inaccurate (due to lack
/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/arch/arm/lib/
H A Dcsumpartialcopygeneric.S156 * the inefficient byte manipulations in the
/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.
/linux/drivers/usb/mon/
H A Dmon_main.c320 * This is obviously inefficient and may be revised in the future.
/linux/lib/math/
H A Ddiv64.c15 * Code generated for this function might be very inefficient
/linux/drivers/gpu/drm/i915/
H A Di915_vma_resource.c143 /* Inefficient open-coded might_lock_irqsave() */ in i915_vma_resource_unhold()

12345