find_or_create_page(9) [centos man page]

FIND_OR_CREATE_PAGE(9)					    Memory Management in Linux					    FIND_OR_CREATE_PAGE(9)

NAME

       find_or_create_page - locate or add a pagecache page

SYNOPSIS

       struct page * find_or_create_page(struct address_space * mapping, pgoff_t index, gfp_t gfp_mask);

ARGUMENTS

       mapping
	   the page's address_space

       index
	   the page's index into the mapping

       gfp_mask
	   page allocation mode

DESCRIPTION

       Looks up the page cache slot at mapping & offset. If there is a page cache page, it is returned locked and with an increased refcount.

       If the page is not present, a new page is allocated using gfp_mask and added to the page cache and the VM's LRU list. The page is returned
       locked and with an increased refcount.

       On memory exhaustion, NULL is returned.

       find_or_create_page may sleep, even if gfp_flags specifies an atomic allocation!

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						    FIND_OR_CREATE_PAGE(9)

JOURNAL_TRY_TO_FREE_(9) 				     The Linux Journalling API					   JOURNAL_TRY_TO_FREE_(9)

NAME

       journal_try_to_free_buffers - try to free page buffers.

SYNOPSIS

       int journal_try_to_free_buffers(journal_t * journal, struct page * page, gfp_t gfp_mask);

ARGUMENTS

       journal
	   journal for operation

       page
	   to try and free

       gfp_mask
	   we use the mask to detect how hard should we try to release buffers. If __GFP_WAIT and __GFP_FS is set, we wait for commit code to
	   release the buffers.

DESCRIPTION

       For all the buffers on this page, if they are fully written out ordered data, move them onto BUF_CLEAN so try_to_free_buffers can reap
       them.

       This function returns non-zero if we wish try_to_free_buffers to be called. We do this if the page is releasable by try_to_free_buffers. We
       also do it if the page has locked or dirty buffers and the caller wants us to perform sync or async writeout.

       This complicates JBD locking somewhat. We aren't protected by the BKL here. We wish to remove the buffer from its committing or running
       transaction's ->t_datalist via __journal_unfile_buffer.

       This may *change* the value of transaction_t->t_datalist, so anyone who looks at t_datalist needs to lock against this function.

       Even worse, someone may be doing a journal_dirty_data on this buffer. So we need to lock against that.  journal_dirty_data will come out of
       the lock with the buffer dirty, which makes it ineligible for release here.

       Who else is affected by this? hmm... Really the only contender is do_get_write_access - it could be looking at the buffer while
       journal_try_to_free_buffer is changing its state. But that cannot happen because we never reallocate freed data as metadata while the data
       is part of a transaction. Yes?

       Return 0 on failure, 1 on success

AUTHORS

       Roger Gammans <rgammans@computer-surgery.co.uk>
	   Author.

       Stephen Tweedie <sct@redhat.com>
	   Author.

COPYRIGHT

Kernel Hackers Manual 2.6.					     July 2010						   JOURNAL_TRY_TO_FREE_(9)