gentoo starts in 37 seconds(not counting bios and grub)
the process generally takes 18 seconds until gnome starts loading whcih takes up the rest
I looked around for a bit and tried many solutions like modularizing unnecessary components of the kernel(wasn't helpful at all), starting service in parallel, disabling some services from the default and boot time...etc

You might find app-benchmarks/bootchart2 and sys-fs/e4rat useful. One will show you where the slowness is coming from, the other preloads files for the boot process (and can optionally defragment them).

What a hardware do you use? How fast is your drive (hdparm -tT)?
18 secs until starting gnome is not a very bad if you do not using ssd drive, but 20 secs for gnome starting - it is too much.
I think it is not a kernel/modules issue.

hdparm indicates bu buffered write speed is 55 mb/s ~
I agree the boot process itself is not so bad, must be something with gnome
Ill try looking around gnome and see if something seems to be taking up all htis time

It is a very fast boot for 55 mb/s read speed disk.
Especially since you are using bloated gnome (assuming it is gnome3).
You can try to reduce your 37 secs, try out e4rat. For slow disks it gives a good improvement.

I see you have systemd, can you run `systemd-analyze blame` and `systemd-analyze critical-chain`; for more details you can opt to run `systemd-analyze plot` and `systemd-analyze dot`, though running the former critical-chain command after optimizing something makes the latter two unnecessary (they are more handy for a good overview).

First concern is that there is a cleanup going on on your ext4, you probably wil want to investigate this if this happens every boot; possibly start a separate topic about it if Google doesn't yield details. I'm not sure how the messages are positioned in time relative to the cleanup, but it appears almost two seconds are lost around here, the orphan cleanup itself indicating it took 1.490165 seconds.

At least half of a second is lost by synchroneously probing your drives, since you only have one HDD and one DVD drive this can be done asynchroneously.

The reason this is synchroneously is because on systems with much more drives spinning them up all at once can possibly cause a power spike;
I have two HDDs and one DVD drive and have this asynchroneously myself, I have not experienced any problems and it made my boot a bit faster.

You can turn this from synchrneously to asynchroneously using `sed -e 's/ahci_ignore_sss/true/g' -i /usr/src/linux/drivers/ata/ahci.c`.

If you don't need USB in order to mount root, you can make sure everything that is USB related is a module so it loads after the kernel mounts root; you likely win half a second here. Generally making things modules instead of built-in where you can is good advice; since I don't directly see something else that spares at least half a second, I suggest you to turn things into modules to win another half second.

So, that covers how you can turn the kernel down to almost under a second; if you share the other information (remember the suggested commands at the top of this post) we can look into the rest.

Ah, I see you have edited your post; for the bootchart image, there's something going wrong there not covering your entire boot, unless you can fix that please run the systemd suggestions from my previous post instead.

I can't run the above command , and emerging systemd will result in udev being removed
ill try modularizeing everything usb related, I also enabled asynchronous driver probing
my boot is now at:
37 seconds

another question though
i thought loading modules was slower if you are going to load the module everytime you boot.
also would an initrd be faster? I've tried one before and it was extremely slow, just thought Id check though

Yeah, that's as far as the kernel goes; most seems to be attributable to the rest of your boot, without more troubleshooting information it's hard to know where the issue lies.

blakdeath wrote:

another question though
i thought loading modules was slower if you are going to load the module everytime you boot.
also would an initrd be faster? I've tried one before and it was extremely slow, just thought Id check though

Loading modules is asynchroneous, by building into the kernel you force them to be loaded before the (re)mount of the root partition; by doing this in the initrd, it gets even worse.

Though, the majority of time that can be improved is after the kernel; I hope you can obtain troubleshooting information for that.