=== AndrewMC is now known as SpockVulcan === Mrokii_ is now known as Mrokii === SpockVulcan is now known as AndrewMC === Dave is now known as Guest53217 === ziroday` is now known as ziroday [13:54] o [14:59] ok, I think I should just start now :) [15:00] allow me to introduce myself. I am Mulyadi Santosa, 31 years old [15:00] currently resides in Indonesia === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Current Session: Understanding fields in /proc/meminfo - Instructors: the_hydra [15:00] and as you can easily guess, I use Linux daily .... [15:01] ok, let's start with easy one "what is /proc/meminfo"? [15:01] and to answer that, you need to know what /proc is.... [15:01] it's a pseudo filesystem [15:02] meaning, it doesn't exist in your disk...be it your hard disk, SSD, floppy etc [15:02] it is entirely created in memory...in run time,by the Linux kernel [15:02] so you see the content of /proc, just like any other normal directory [15:03] /proc/meminfo holds almost all information you need about your virtual memory condition [15:04] and, perhaps it might surprise you, tools such as top, vmstat, atop, htop and others parse /proc/meminfo to gather information about virtual memory [15:04] up to this point, any question? [15:05] none? ok let's continue [15:05] MemTotal....what is this field supposed to mean? [15:05] your entire RAM? [15:06] anybody wanna bravely guess? [15:09] total RAM [15:09] close... [15:09] else? [15:10] ok, it's actually total amount of RAM recognized and "mappable" by your kernel [15:10] +swap [15:10] this might sound like a rocket science for seconds :) [15:10] 2^32 [15:10] what if I told you, that initially, linux kernel could only manage up to 896 MiB? [15:11] this is due to ...what the geek call...virtual memory spliy [15:11] split [15:11] in 32 bit machine, in total, we could address up to 4 GiB...2^32 [15:12] in this address space, linux kernel split it into two [15:12] 3 GiB for user space, 1 GiB for the kernel itself [15:12] so within this 1 GiB space, kernel must fit everything regarding memory allocation [15:12] and you might further ask "ok 1 GiB..but you say 896 MiB? how's that?" [15:13] kernel...reserve more or less 128 for special needs [15:13] so, enough to say that, without additional "hacks", Linux kernel...initially could only address up to 896 MiB [15:14] so, for those of you who owns aging distro like redhat 5.2, don't scream if you put 4 GiB RAM module in your machine and scream "why on earth, it's just showing 896 MB? crap" [15:15] luckily, modern distro now equipped with default kernel which is able to address up to 4 GiB [15:15] this is called highmem [15:15] how about machine with RAM up to 64 GiB? [15:16] Ooh! Virtual MMU! [15:16] assuming your processor has PAE (Processor Address Extension) flag ( grep -i pae /proc/meminfo), just install pae kernel package [15:16] and kazaam, 64 GiB room for you [15:17] but wait, you said 64 GiB..but uhm, this is 32 bit you know? [15:17] yeah, that's what PAE is...to "extend" addressing [15:17] slight pause here...any question? [15:18] this is a generic knowledge, so it's not limited for Ubuntu and its family only... [15:18] every Linux distro apply the same thing here... [15:18] flan, yeah MMU.... [15:18] flan, you got it right :) [15:19] allow me to gently remind you, it's all described in my article...in Full circle magazine issue 39...page 14 to 20 [15:20] so, in case you need longer explanation, you might download and read it there [15:20] ok guys...I move again.. [15:20] Technical question, asked only out of curiosity and not for practical relevance: would PAE emulate MMU functionality for devices that have no real MMU of their own? [15:20] Like ancient Palms. [15:20] nope AFAIK [15:21] PAE is PAE [15:21] MMU is MMU [15:21] in other word, without MMU, there won't be virtual memory [15:21] PAE just deal with addressing [15:21] Okay, so it's a pre-requisite. [15:21] think like this: MMU is like your office rooms [15:22] it segments a floor into smaller...ehm, how to say that..cubicles [15:22] where are you going to get intel hardware without an MMU anyway? [15:22] I was thinking ancient ARM. [15:22] flan, nice question anyway [15:22] But this is getting off-topic. [15:22] PAE is an x86 only thing isn't it? [15:22] ok, shall I continue? [15:22] mhall119, AFAIK yes [15:23] mhall119, but it could be named something else in other platform [15:23] ok, memfree..this one is also confusing sometimes [15:23] again, let me ask, what's your understanding about it? [15:23] one person at a time, ok? :D [15:24] nobody? ok.... memfree is total amount of your RAM...100% unused for nothing! [15:24] The amount of memory not occupied by anything cached or loaded by the kernel. [15:24] sorry i mean, unused for every purpose [15:25] flan, thanks...that's almost similar like mine :) [15:26] ok, so, in memfree, not just your application's allocated memory determines it, but also how much kernel does caching and any other kind of allocation [15:27] so if you see it and think "what? i just by my super dooper 16 GiB RAM stick and it is chewed down to 8 GiB in just few hours while I just sit and explore web using my great firefox?" [15:28] that's the answer....firefox allocates...kernel might do caching..and so on [15:28] but that's good [15:28] and you might say "are you nuts???" [15:28] no I am not [15:29] think like this: suppose you really have 16 GiB...and kernel use it to cache your recent read files for about 10 GiB (ok, this might sound exaggerating..) [15:29] then, for next access, kernel will simply read from in-RAM cache instead of reading your disk [15:29] isn't that nice? [15:30] you get speed up, people! :D [15:30] But I like hearing my HDD thrash. :( [15:31] flan, a strong magnetic iron will do that much quicker :D [15:31] ehheheh [15:31] coupling that, is buffer and cache [15:31] actually, they are more or less same thing [15:32] "page cache" a.k.a disk cache [15:32] so you sum them both, and you get the amount of RAM used for disk caching... [15:32] pretty simple... [15:33] ok...no question so far? [15:33] I shall jump to Committed_AS [15:33] if you wanna know how much RAM your applications ask for memory, this is the indicator [15:34] please notice, there is different between "how much an application ask" and "how much it is really allocated for now" [15:34] committed_as reflect the first one...the "request" [15:35] thus, the higher this field, you know there is a memory chewing application running..especially when it constantly increase [15:35] but it never exceed commitlimit [15:35] this is the upper limit, dynamically set by kernel...that denotes how much virtual memory you can ask [15:36] so "great, you make me dizzy, please show me how much RAM is really allocated by my applications...." [15:36] AnonPages tells you that [15:37] Anon...short of Anonymous...is a technical way to say "a page that has no physical disk/file backing" [15:37] ever use malloc() in C/C++, people? [15:37] malloc() is one of the function that ask for anonymous pages [15:38] Also new and del for C++, mirrored by higher-level languages, like Java. [15:38] page itself is a smallest unit of RAM that a processor+MMU deal with your RAM [15:38] just like sector in disk... [15:38] flan, yeap [15:39] but...let me tell you, malloc() isn't directly allocate memory for you [15:39] it's just "asking" [15:39] the real deal happen when you access the allocated memory for the first, hence triggerring what the kernel geek calls "page fault" [15:40] swap total and swap free...easy....swap total denotes your total *active* swap area [15:41] the active ones...please notice that [15:41] so if you swapoff a swap area...it will be out of ring [15:41] swap free....the unallocated swap space from the active swaps [15:41] QUESTION: What happens if you swapoff a partition while it's in use? [15:41] 'til now, questions? [15:42] flan, first, kernel check if there is sufficient of free RAM that can contain the bits in there [15:42] so say, it holds 128 MiB of data [15:42] your free RAM, must at least have that amount [15:43] because, if not, it must be kicked out again to swap.... [15:43] agree here? [15:43] Yes, thus far. [15:43] But I'm really asking because I've never tried it. [15:43] and...dynamically, it will be swapped in to RAM [15:43] relax, i did it hundreds of time :D [15:44] and read the codes in linux kernel...so I can tell :) [15:44] once it all in RAM, that swap is detached [15:44] but your application "don't feel it" [15:44] you just feel few glitches....if there's any [15:45] in fact, doing swapoff -a followed by swapon -a (but please, do it carefully) is an easy way to bring all your swapped out pages back to RAM :D [15:46] So what if there isn't enough free RAM/other swap? Will the kernel refuse to complete the command? [15:46] linux kernel has tendency to swap out inactive pages...slowly to swap areas [15:46] (Yay for vm.swappiness) [15:46] thus freeing precious RAM..for more useful things [15:46] flan, yes...correct [15:46] flan, correct again... [15:47] the lower vm.swappiness is, everything will last longer in RAM [15:47] OTOH, the bigger it is (max is 100), it will be swapped out fairly fast [15:48] which one is ideal? up to you...but IMHO 60..the default...is already a nice number [15:48] did I say inactive? [15:48] active? [15:48] yes, kernel marks pages which has been inactive for certain interval [15:48] and they are candidates to be swapped out [15:49] You were talking about active swap areas. [15:49] nope, in-RAM [15:49] Oh, in terms of swap-propagation. [15:49] for swaps, there is no active-inactive :) [15:49] active..denotes portion of RAM that frequently accessed [15:50] I should probably stop derailing your lesson. [15:50] the field itself is splitted into 2, anon..and file [15:50] flan, we can continue in other related ubuntu chat room L) [15:50] :) [15:50] anon...is the anonymous [15:51] and ...file? ok, remember when I talk about cache? this is it..along with the so called file memory mapping [15:51] this sounds geek ...but really you see it everyday [15:51] library loading...primarily :) [15:51] so, big anon...aggresive malloc() [15:52] big file (both active and inactive), could be aggresive library loading etc [15:53] unevictable...mlocked..are portion of RAM that is made unswappable [15:53] most likely, it is allocated by kernel for special need [15:53] or if you're multimedia people who works on audio recording etc, this number might rise... [15:53] it is a standard way to lessen latency [15:54] by locking allocated memory to be always in RAM, it's guaranteed that the access time is fast...because if it hits swap..well you know the consequences :D [15:54] ok, quite fast I guess...questions? [15:54] i selected the most important fields so far... [15:55] this is really linux memory management 101 :D [15:55] i feel like mel gorman junior :D [15:56] ok ...i guess time still permits [15:56] "dirty" [15:56] oh my god, dirty? dirt in my RAM [15:56] enough to say that, when you write something to disk, it's not done right away [15:56] most likely, it's deferred [15:57] portion of RAM that contains bits that haven't been pushed back to the related files..is said to be dirt [15:57] y [15:57] thus, the higher this number might mean : your disk is busy...or something is not optimal with write back operation [15:58] questions? [15:58] Nope. [15:58] others? === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || [16:01] Thank you very much, the_hydra. I definitely learned a few things I didn't know about today. :) [16:01] thanks [16:01] :) [16:01] that would be a great honour === efm_ is now known as efm