lkml.org 
[lkml]   [2015]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] free_pages stuff
On Mon, Dec 21, 2015 at 05:23:11PM -0800, Linus Torvalds wrote:

> And if the code really explicitly wants a page (or set of aligned
> pages) for some vm reason, I suspect having the cast there isn't a bad
> thing. It's clearly not just a random pointer allocation if the bit
> pattern of the pointer matters.
>
> And yes, most of the people who used to want "unsigned long" have long
> since been converted to take "struct page *" instead, since things
> like the VM wants highmem pages etc. There's a reason why the
> historical interface returns "unsigned long": it _used_ to be the
> right thing for a lot of code. The fact that there now are more casts
> than not are about changing use patterns, but I don't think that means
> that we should change the calling convention that has a historical
> reason for it.

Umm... Depends on how early you look. In 0.01:
fs/exec.c:179: if (!(page[i]=get_free_page()))
fs/inode.c:208: if (!(inode->i_size=get_free_page())) {
kernel/fork.c:70: p = (struct task_struct *) get_free_page();
mm/memory.c:143: if (!(to_page_table = (unsigned long *) get_free_page()))
mm/memory.c:185: if (!(tmp=get_free_page()))
mm/memory.c:203: if (!(new_page=get_free_page()))
mm/memory.c:241: if (tmp=get_free_page())

the last 3 are "we want struct page *" variety, the rest is "want a pointer"
stuff (exec.c one is copy_strings() and the only use of pages[...] is a cast
to char *, inode.c one is get_pipe_inode() - I guess you didn't want to bother
with adding pipe-specific fields to struct inode at that point and since
->i_size is unused for pipes anyway reused it to keep a pointer to pipe
buffer). Even then it wasn't the majority.

By 2.0 (still before highmem) the fraction was already _way_ below 50%...


\
 
 \ /
  Last update: 2015-12-22 04:41    [W:0.257 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site