Announcement

Collapse
No announcement yet.

Intel GPU Driver Tries To Rip Out FBDEV Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    That's not easy to answer. Basically make menuconfig and start unchecking options you don't use. Easier said than done though. localmodconfig may be useful for you to determine what to keep and what to toss.

    EDIT: along with localmodconfig you may also want to use a kernel seed. http://kernel-seeds.org/
    Last edited by duby229; 06-20-2013, 06:50 PM.

    Comment


    • #47
      Originally posted by Ericg View Post
      Ideas for how? I've always just put up with it but I'd be open to improvements.
      Considering how much time is spent on modules, try running "make localmodconfig"-it will take the list of loaded modules and enable just those. Of course, you'd better plug in hardware that you'll want to use first, so the modules are loaded. And if you plan to use samba/NTFS/fat, check the filesystems menu (ntfs-3g needs fuse, not kernel ntfs!).
      Once you have a working config, you can keep using it via make oldconfig.

      Also, why the need to patch the Intel driver?

      ...
      By the way, THIS is the big reason that needing extra packages gets annoying. It takes a while to build a kernel, but if you also need to get the latest udev, libdrm, libxkbcommon, etc. that can really get old. And no, I don't intend to stop updating the kernel on my Squeeze system...
      Last edited by Ibidem; 06-20-2013, 07:19 PM.

      Comment


      • #48
        Originally posted by Ibidem View Post
        Considering how much time is spent on modules, try running "make localmodconfig"-it will take the list of loaded modules and enable just those. Of course, you'd better plug in hardware that you'll want to use first, so the modules are loaded. And if you plan to use samba/NTFS/fat, check the filesystems menu (ntfs-3g needs fuse, not kernel ntfs!).
        Once you have a working config, you can keep using it via make oldconfig.

        Also, why the need to patch the Intel driver?

        ...
        By the way, THIS is the big reason that needing extra packages gets annoying. It takes a while to build a kernel, but if you also need to get the latest udev, libdrm, libxkbcommon, etc. that can really get old. And no, I don't intend to stop updating the kernel on my Squeeze system...
        1) I've known about localmodconfig but I've never run it because i know that I'm gonna forget something and I won't realize it until I need it in an emergency.

        2) Patch: https://bugzilla.kernel.org/show_bug.cgi?id=47941#c83 Hardware Quirk that makes the backlight have an acid-trip, because Dell did SUCH a good job of making the XPS 13z Sandy bridge model be "linux certified" -.-

        3) Compiling some things doesn't bother me, I run Arch and Fedora mostly so I'm used to either compiling via the AUR or compiling from git because there werent RPM packages available. But I HATE the thought of reliving my attempted-Gentoo-days where I had to compile every little thing.

        Comment


        • #49
          Compile times really arent that bad on newer hardware. I remember when I first started with gentoo. I was on a 300C Celeron. It was OC'd to 600mhz though. That was the only chip I ever had that I could double the clock. Still took days to compile everything... Now with a 955BE it takes a few hours.

          Comment


          • #50
            Originally posted by Ericg View Post
            make clean, reran oldconfig,bzimage and modules...

            Code:
            ...
            real    29m54.490s
            user    101m40.549s
            sys     8m56.427s
            [eric@eric-laptop linux-3.9.5]$
            Odd... I seem to remember this taking longer the first time I did it just a month or so ago...

            Either i timed it with 1 job, there was something else hogging the CPU, (This was run with me still using firefox occasionally, it had the CPU to itself most of the time when I ran it but not all the time), or having yakuake not visible decreases the priority of whatever is running and therefore slows down the compile.
            Use top to see what's hogging your CPU.
            Building the kernel, unless you're building 99% of all modules, should be well under 10M. 2-3 on a strong machine.

            BTW, what's your machine hardware configuration (unless I missed it).

            - Gilboa
            DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
            SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
            BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
            LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

            Comment


            • #51
              Originally posted by gilboa View Post
              Use top to see what's hogging your CPU.
              Building the kernel, unless you're building 99% of all modules, should be well under 10M. 2-3 on a strong machine.

              BTW, what's your machine hardware configuration (unless I missed it).

              - Gilboa
              I gotta recompile anyway to test a patch, so I'll see what happens.


              Machine configuration:

              CPU is an Intel i5-2467M clocked at 1.6GHz, dual-core + HT
              Ondemand goveror
              4GB's of RAM
              3.2GB's of SWAP
              HDD's is an SSD, i forget what make and model though.
              Only other speed-bump i could really think of would be to move the sources to /tmp and compile it in /tmp. Since /tmp is tmpfs, shouldn't that run the entire compile straight in RAM instead of hitting the SSD?
              Last edited by Ericg; 06-24-2013, 01:07 PM.

              Comment


              • #52
                Originally posted by Ericg View Post
                I gotta recompile anyway to test a patch, so I'll see what happens.


                Machine configuration:

                CPU is an Intel i5-2467M clocked at 1.6GHz, dual-core + HT
                Ondemand goveror
                4GB's of RAM
                3.2GB's of SWAP
                HDD's is an SSD, i forget what make and model though.
                Only other speed-bump i could really think of would be to move the sources to /tmp and compile it in /tmp. Since /tmp is tmpfs, shouldn't that run the entire compile straight in RAM instead of hitting the SSD?
                30m with an SSD?!?!?!
                Does your ssd mount options include discard?
                Do you have encryption on your build directory?


                EDIT:
                Come to think about you, are testing oldconfig, right?
                I'm so used to building the kernel with optimized (read: small) configuration, I forgot how huge the default .config is.
                ... So, given the (as far as I remember) size of default configuration, 30m on a fairly low-end machine is more-or-less OK.

                However, the build is very IO intensive, at least on my Xeon workstation (12C/24T, 36GB, 6x300GB in RAID6) the software RAID is the main limiting factor when building the kernel.
                The SSD should have been able to improve this figure by a fairly large margin.

                - Gilboa
                Last edited by gilboa; 06-24-2013, 02:50 PM.
                DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                Comment


                • #53
                  Originally posted by gilboa View Post
                  30m with an SSD?!?!?!
                  Does your ssd mount options include discard?
                  Do you have encryption on your build directory?

                  - Gilboa
                  Yes; and No.

                  Discard isn't necessary for some SSD's, as its handled by the firmware automatically, unfortunately for me... in this one, it is not. Therefore I have to specify it at mount time, or let cron/systemd handle it.

                  No encryption on the build directory, but btrfs is set to compress

                  And yes its oldconfig -- fedora default config, as such im sure just about every module is set to be compiled lol
                  Last edited by Ericg; 06-24-2013, 02:54 PM.

                  Comment


                  • #54
                    Just ran oldconfig.

                    $ make -j 24
                    real 11m1.545s
                    user 83m40.261s
                    sys 10m17.770s

                    $ find | grep .ko$ | wc -l
                    2479

                    Given the huge number of (default) modules, 30+ on a low end (read: mobile) i5 is acceptable.

                    EDIT:
                    Noticed my kernel build was still using my secure (encrypted) ccache. Recreated a new ccache home in unencrpyted partition and redid the build on fresh new kernel copy.
                    (Also bumped the jobs number... just in-case)

                    $ make -j 36
                    real 5m4.928s
                    user 89m12.660s
                    sys 10m51.218s

                    - Gilboa
                    Last edited by gilboa; 06-24-2013, 03:16 PM.
                    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                    Comment


                    • #55
                      Originally posted by gilboa View Post
                      Just ran oldconfig.

                      $ make -j 24
                      real 11m1.545s
                      user 83m40.261s
                      sys 10m17.770s

                      $ find | grep .ko$ | wc -l
                      2479

                      Given the huge number of (default) modules, 30+ on a low end (read: mobile) i5 is acceptable.

                      EDIT:
                      Noticed my kernel build was still using my secure (encrypted) ccache. Recreated a new ccache home in unencrpyted partition and redid the build on fresh new kernel copy.
                      (Also bumped the jobs number... just in-case)

                      $ make -j 36
                      real 5m4.928s
                      user 89m12.660s
                      sys 10m51.218s

                      - Gilboa

                      compiling in RAM, and a localmodconfig cut the compile time down to about 15-20minutes (forgot to add time onto the end, just kept an eye on the clock)

                      Thanks for all your helps guys. Much appreciated.

                      Comment

                      Working...
                      X