mm/swap.c
Source file repositories/reference/linux-study-clean/mm/swap.c
File Facts
- System
- Linux kernel
- Corpus path
mm/swap.c- Extension
.c- Size
- 33647 bytes
- Lines
- 1206
- Domain
- Core OS
- Bucket
- Memory Management
- Inferred role
- Core OS: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/mm.hlinux/sched.hlinux/kernel_stat.hlinux/swap.hlinux/mman.hlinux/pagemap.hlinux/folio_batch.hlinux/init.hlinux/export.hlinux/mm_inline.hlinux/percpu_counter.hlinux/memremap.hlinux/percpu.hlinux/cpu.hlinux/notifier.hlinux/backing-dev.hlinux/memcontrol.hlinux/gfp.hlinux/uio.hlinux/hugetlb.hlinux/page_idle.hlinux/local_lock.hlinux/buffer_head.hinternal.htrace/events/pagemap.h
Detected Declarations
struct cpu_fbatchesfunction __page_cache_releasefunction page_cache_releasefunction __folio_putfunction lru_addfunction smp_mb__after_atomicfunction folio_batch_move_lrufunction __folio_batch_add_and_movefunction offsetoffunction folio_rotate_reclaimablefunction lru_note_cost_unlock_irqfunction lru_note_cost_refaultfunction lru_activatefunction folio_activate_drainfunction folio_activatefunction folio_activate_drainfunction __lru_cache_activate_foliofunction lru_gen_inc_refsfunction lru_gen_clear_refsfunction lru_gen_inc_refsfunction __folio_set_referencedfunction folio_mark_accessedfunction lru_gen_folio_seqfunction folio_add_lru_vmafunction lru_deactivate_filefunction lru_deactivatefunction lru_lazyfreefunction lru_add_drain_cpufunction deactivate_file_foliofunction folio_deactivatefunction folio_mark_lazyfreefunction lru_add_drainfunction lru_add_and_bh_lrus_drainfunction lru_add_drain_cpu_zonefunction lru_add_drain_per_cpufunction cpu_needs_drainfunction __lru_add_drain_allfunction lru_add_drain_allfunction lru_add_drain_allfunction lru_cache_disablefunction folios_put_refsfunction release_pagesfunction __folio_batch_releasefunction folio_batch_remove_exceptionalsfunction lruvec_reparent_lrufunction for_each_managed_zone_pgdatfunction lru_reparent_memcgfunction swap_setup
Annotated Snippet
struct cpu_fbatches {
/*
* The following folio batches are grouped together because they are protected
* by disabling preemption (and interrupts remain enabled).
*/
local_lock_t lock;
struct folio_batch lru_add;
struct folio_batch lru_deactivate_file;
struct folio_batch lru_deactivate;
struct folio_batch lru_lazyfree;
#ifdef CONFIG_SMP
struct folio_batch lru_activate;
#endif
/* Protecting the following batches which require disabling interrupts */
local_lock_t lock_irq;
struct folio_batch lru_move_tail;
};
static DEFINE_PER_CPU(struct cpu_fbatches, cpu_fbatches) = {
.lock = INIT_LOCAL_LOCK(lock),
.lock_irq = INIT_LOCAL_LOCK(lock_irq),
};
static void __page_cache_release(struct folio *folio, struct lruvec **lruvecp,
unsigned long *flagsp)
{
if (folio_test_lru(folio)) {
folio_lruvec_relock_irqsave(folio, lruvecp, flagsp);
lruvec_del_folio(*lruvecp, folio);
__folio_clear_lru_flags(folio);
}
}
/*
* This path almost never happens for VM activity - pages are normally freed
* in batches. But it gets used by networking - and for compound pages.
*/
static void page_cache_release(struct folio *folio)
{
struct lruvec *lruvec = NULL;
unsigned long flags;
__page_cache_release(folio, &lruvec, &flags);
if (lruvec)
lruvec_unlock_irqrestore(lruvec, flags);
}
void __folio_put(struct folio *folio)
{
if (unlikely(folio_is_zone_device(folio))) {
free_zone_device_folio(folio);
return;
}
if (folio_test_hugetlb(folio)) {
free_huge_folio(folio);
return;
}
page_cache_release(folio);
folio_unqueue_deferred_split(folio);
mem_cgroup_uncharge(folio);
free_frozen_pages(&folio->page, folio_order(folio));
}
EXPORT_SYMBOL(__folio_put);
typedef void (*move_fn_t)(struct lruvec *lruvec, struct folio *folio);
static void lru_add(struct lruvec *lruvec, struct folio *folio)
{
int was_unevictable = folio_test_clear_unevictable(folio);
long nr_pages = folio_nr_pages(folio);
VM_BUG_ON_FOLIO(folio_test_lru(folio), folio);
/*
* Is an smp_mb__after_atomic() still required here, before
* folio_evictable() tests the mlocked flag, to rule out the possibility
* of stranding an evictable folio on an unevictable LRU? I think
* not, because __munlock_folio() only clears the mlocked flag
* while the LRU lock is held.
*
* (That is not true of __page_cache_release(), and not necessarily
* true of folios_put(): but those only clear the mlocked flag after
* folio_put_testzero() has excluded any other users of the folio.)
*/
if (folio_evictable(folio)) {
if (was_unevictable)
__count_vm_events(UNEVICTABLE_PGRESCUED, nr_pages);
} else {
Annotation
- Immediate include surface: `linux/mm.h`, `linux/sched.h`, `linux/kernel_stat.h`, `linux/swap.h`, `linux/mman.h`, `linux/pagemap.h`, `linux/folio_batch.h`, `linux/init.h`.
- Detected declarations: `struct cpu_fbatches`, `function __page_cache_release`, `function page_cache_release`, `function __folio_put`, `function lru_add`, `function smp_mb__after_atomic`, `function folio_batch_move_lru`, `function __folio_batch_add_and_move`, `function offsetof`, `function folio_rotate_reclaimable`.
- Atlas domain: Core OS / Memory Management.
- Implementation status: integration implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.