From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: How to test a syscall prior to compiling the kernel
Date: Wed, 4 Jun 2014 15:14:45 -0700 [thread overview]
Message-ID: <20140604221445.GA15526@kroah.com> (raw)
In-Reply-To: <CAJUuVQ4=p=Eb5ub+-LCB1Uj-28ZD9406grgizgqXg4vS=9617w@mail.gmail.com>
On Wed, Jun 04, 2014 at 03:02:02PM -0400, Andev wrote:
> On Wed, Jun 4, 2014 at 2:33 PM, Andev <debiandev@gmail.com> wrote:
> > On Wed, Jun 4, 2014 at 1:56 PM, <Valdis.Kletnieks@vt.edu> wrote:
> >>
> >> The trick to remember is that you probably don't want to use the ramdisk
> >> as the permanent host, so...
> >>
> >> 1) Setup your git tree on permanent storage
> >> 2) Set up your ramdisk
> >> 3) cd /my/source/tree
> >> 4) tar -c --exclude=.git -f - . | (cd /mnt/ramdisk && tar -xvf -)
> >>
> >> then cd /mnt/ramdisk and start building. Remember if you make changes to
> >> copy them back to /my/source/tree :)
> >>
> >> (The --exclude=.git will avoid copying about 900M onto the ramdisk. Skip that
> >> if you need the git history on the ramdisk for doing a bisect or similar)
> >
> > Thanks Valdis for the instructions.
> >
> > So I tried the following to mount a tmpfs
> >
> > $ sudo mount -t tmpfs -o size=2000m tmpfs ./ramlinux/
> > $ tar -c --exclude=.git -f - . | (cd ~/ramlinux && tar -xvf -)
> >
> > And it works fine. I am not sure if tmpfs has any advantages over ramdisk.
> >
>
> So I might have jumped the bullet on saying that it works fine. I see
> no difference between the compilation speed on native disk vs tmpfs.
Then perhaps disk I/O is not your limiting factor, but compute power is.
> For a defconfig this is the time I get:
>
> real 6m35.407s
> user 10m3.734s
> sys 1m0.514s
I don't know your hardware setup, but that seems a bit slow, are you
building with all processors "full"? You should always add
-j NUMBER" to your kernel make command, where NUMBER is 2x the number of
CPUs you have in the box.
Good luck,
greg k-h
prev parent reply other threads:[~2014-06-04 22:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 3:22 How to test a syscall prior to compiling the kernel Dipanjan Das
2014-06-04 3:52 ` Greg KH
2014-06-04 3:59 ` Dipanjan Das
2014-06-04 4:14 ` Augusto Mecking Caringi
2014-06-04 4:19 ` Greg KH
[not found] ` <CAOUBrm3BQyVJys4++o6zPUVxp7+dDSvPiF9MFpOUzSLpyzhN7g@mail.gmail.com>
2014-06-04 8:24 ` navid Rahimi
2014-06-04 15:51 ` Andev
2014-06-04 17:56 ` Valdis.Kletnieks at vt.edu
2014-06-04 18:33 ` Andev
2014-06-04 18:42 ` Greg KH
2014-06-04 19:02 ` Andev
2014-06-04 22:14 ` Greg KH [this message]
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=20140604221445.GA15526@kroah.com \
--to=greg@kroah.com \
--cc=kernelnewbies@lists.kernelnewbies.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.