From: Erik van Konijnenburg <ekonijn@xs4all.nl>
To: Dave Jones <davej@suse.de>, Andrew Morton <akpm@zip.com.au>
Cc: Christoph Hellwig <hch@infradead.org>,
kernel-janitor-discuss@lists.sourceforge.net, linux-mm@kvack.org
Subject: Re: page-flags.h
Date: Sat, 4 May 2002 08:46:33 +0200 [thread overview]
Message-ID: <200205040646.g446kZrO008548@smtpzilla5.xs4all.nl> (raw)
In-Reply-To: <20020504013938.G30500@suse.de>
With pagemap.h being the worst of the lot. Why is this?
In principle it's just some declarations for functions that take
structure pointers as arguments and interesting defines like
#define page_cache_get(x) get_page(x)
You don't need include files to compile that: the compiler is perfectly
capable of translating a structure pointer without knowing what's
inside the structure.
What hurts are the static inline functions; these access structure
fields and do need the structure definitions, sucking in all those
includes. For pagemap.h, just three functions are responsible for
an 82Kb callgraph: page_cache_alloc, add_to_page_cache,
wait_on_page_locked.
So what we do is remove all includes and the three evil inline functions
from pagemap.h and put them in pagemap-bonus.h. Include pagemap-bonus.h
only in the 10 or so files that use it.
Alternatively, put the meat of pagemap.h in a pagemap-diet.h, and leave
the includes and static inlines in pagemap.h; that would make for easier
transition to faster compile times. I guess something similar can be done
for the other big three.
The plan would be not to flatten the complete include graph,
but only to avoid the overhead of deeply nested include hierarchies
that are caused by static inline.
Regards,
Erik
On Saturday 04 May 2002 01:39 am, Dave Jones wrote:
> On Fri, May 03, 2002 at 04:06:05PM -0700, Andrew Morton wrote:
> > Part of my uncertainty here is that we just don't seem to
> > have a "plan". Is the objective to completely flatten
> > the include heirarchy, no nested includes, and make all
> > .c files include all headers to which they (and their included
> > headers) refer?
> >
> > That's pretty aggressive, but I think it's the only sane
> > objective.
>
> <linux/fs.h>, <linux/mm.h>, <linux/sched.h>, <linux/pagemap.h>
> are usually the main culprits. Each of these suckers pulls in
> dozens and dozens of includes.
> Dave.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2002-05-04 6:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020501192737.R29327@suse.de>
2002-05-01 17:34 ` page-flags.h Christoph Hellwig
2002-05-01 18:04 ` page-flags.h Dave Jones
2002-05-03 2:52 ` page-flags.h Andrew Morton
2002-05-03 8:24 ` page-flags.h Christoph Hellwig
2002-05-03 22:41 ` page-flags.h Erik van Konijnenburg
2002-05-03 23:06 ` page-flags.h Andrew Morton
2002-05-03 23:39 ` page-flags.h Dave Jones
2002-05-04 6:46 ` Erik van Konijnenburg [this message]
2002-05-14 20:25 ` page-flags.h Andrew Morton
2002-05-15 12:38 ` page-flags.h Christoph Hellwig
2002-08-29 19:04 ` page-flags.h Daniel Phillips
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200205040646.g446kZrO008548@smtpzilla5.xs4all.nl \
--to=ekonijn@xs4all.nl \
--cc=akpm@zip.com.au \
--cc=davej@suse.de \
--cc=hch@infradead.org \
--cc=kernel-janitor-discuss@lists.sourceforge.net \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox