LinuxCon Europe Konferansı

Bu yıl 5-7 Ekim tarihlerinde LinuxCon + CloudOpen + ELC Europe etkinliği İrlanda, Dablin'de düzenlendi. Ben bu sene LinuxCon'a ilk kez ve konuşmacı olarak katıldım ^_^.

Outreachy stajyerlerine çalıştıkları projenin konferanslarından birine katılmaları için etkinlik bileti + $500 burs veriyor. Bu şekilde stajyerlerin iş bulabilme ihtimali de artıyor. Ben de geçtiğimiz kış Outreachy'de stajyer olduğum için bu bursu almaya hak kazandım.

Mümkün olduğunca bu tür etkinliklere katılmaya çalışıyorum. Yeni ülkeler, yeni insanlar görmek gerçekten çok güzel. Hem bu sayede çevremi de genişletmiş oluyorum. Zaten onlar da yeni insanlar tanımaya, konuşmaya çok hevesli.

Bu yıl şöyle bir durum oldu. Linux Vakfı Diversity Scholarship adı altında konferansa katılım bileti vermeye başladı. Outreachy zaten konferansa ücretsiz katılım sağlıyordu ama Julia (Outreachy'de Linux Kernel koordinatörü), bu bursa başvurmamızı önerdi. Biz (stajyerler) de başvurduk ve alındık. İtiraf ediyorum, konuşma yapacağım için alınmayı bekliyordum. Bu sefer şaşırmadım :p

LinuxCon'un ilk günü kayıtlar 7.15'te başladı. Genelde insanlar geç gelseler de biz yeni olduğumuz için vaktinde etkinlik yerinde olduk :). Etkinlik Convention Centre Dublin 'de yapıldı. Orası geçen yıl Dublin'e gittiğimde ışıl ışıl olmasıyla ilgimi çeken yer. Bir sene sonra orada sunum yapacaksın deseler inş. cnm yha derdim :). CCD'nin harika ötesi fotoğrafına bakmak için bu linke tıklayabilirsiniz.

Etkinlikte Julia, Daniel ve Greg ile tanışma fırsatım oldu. Aynı zamanda stajyer olan arkadaşlarla da tanışmış oldum. Etkinliğin ilk akşamı konuşmacılar için düzenlenen yemeğe katıldım. Birkaç servis insanları götürmek için CCD'ye gelmişti. Bu sırada Torvalds gelip önüme oturdu. Tabi bende hafif bir taşikardi ;)

Torvalds servise geldiğinde hafif bir alkış olsa da yanımdaki çekirdek geliştiricileri çekingen gibi duruyorlardı. Bu nedenle ben de Torvalds ile konuşmadım ama Torvalds ile aynı servise binmişliğim var diye cv'me yazayım diyorum.

Konferansta Rik'le (stajdaki danışmanım) görüşmeyi ümit etmiştim. Etkinlik sabahı Rik'e seni göremedim, hangi sunumdasın diye yazdım. Senede 2-3 konferansa katılabildiğim için buna gelmedim dedi. Tabi o böyle diyince içime gnu oturdu :(. Muhtemelen Amerika'da daha fazla etkinlik oluyordur diye düşündüm.

Acaba Sarah Sharp gelmiş midir? diye düşünürken akşama doğru Sarah'nın bu yazısını gördüm. Sarah bilgisayar bilimlerinde birçok kadını destekleyip, cesaretlendirdi. Hala daha devam ediyor. Geçtiğimiz dönem Red Hat'in kadınlar için düzenlediği Açık Kaynak Ödülleri'ni kazanmıştı. Sarah'nın Linux çekirdeği camiasından ayrılması gerçekten üzücü ancak tüm bunlar bir yana, insanın hayatında yer verdiği şeylere bir noktadan sonra dur diyebilmesi bence çok güzel bir davranış.

Geçen yıl gönderdiğim yamalara cevap alamayınca, ilk Sarah'ya sormuştum :). Yanlış bir şey mi yapıyorum, neden kimse cevaplamıyor? diye. Linux çekirdeği merge window sürecinde bu yüzden yeni yama kabul etmiyorlar demişti. O zamanlar Linux çekirdeğinde çok yeniydim (hala çok yeniyim :|) , okuldaki son yılımdı. Alanında lider insanların kendilerini yeni başlayanlara bile konuşacak kadar yakın hissettirmesi gerçekten harika bir şey. Dilerim dünyada daha fazla böyle güzel insanlar var olur.

Bu konudan sonra etkinliğe geri dönelim :p. Etkinliğin ilk günü oldukça heyecanlı ve yorucu geçti. Zaten sabah altıda kalkmıştım (etkinlik 7.15te olunca) :).  İkinci gün üzerimdeki heyecanı, stresi atıp sanki ertesi gün sunum yapacak olan ben değilmişim rahatlığında günümü geçirdim. Genelde Linux çekirdeği ile ilgili sunumlara katıldım, bazı sunumlarda çok fazla bilmediğim anahtar kelime olduğundan anlamakta zorlandım :|. 2. gün SanDisk'in sponsorluğunda kadınlara özel öğle yemeği düzenlendi. Yemek sonrasında kadınların bilişim dünyasındaki yeri, geliştirici topluluklarda kadınların genelde kendini geriye çekmesinden bahsedildi. Günümüzde insanların hala ırkı, rengi, LGTB'ye dahil olmaları gibi sebeplerle dışlandıklarından konuşuldu.

Ben de bu yıl ilk kez 100 kişilik sunum salonlarında 1-2 kadın olmasının nasıl bir durum olduğunu görmüş oldum. Outreachy Linux çekirdeği camiasındaki kadın-erkek dengesini sağlamak için gerçekten çok güzel bir adım. Outreachy'de sadece Linux Vakfı yok elbette. Mozilla, WikiMedia, Xen ve daha fazlası için bknz: katılan organizasyonlar.

Etkinliğin 3. günü Outreachy panelinde sunum yaptık. İlk önce Julia Outreachy'nin genel amaçlarından, nasıl işlediğinden bahsetti. Bu yıl Hindistan'dan gelecek olan stajyer arkadaşlar katılamadılar. İrlanda, Hindistan için vize vermemiş. Nasıl olur insan gerçekten anlayamıyor ama ..

Sunumu dinlemeye gelen kitle beklediğim kadar kalabalık olmadı ama yine de stajyerler olarak heyecandan ölmek üzere sunum yapmış olabiliriz :).

LinuxCon deneyimim benim için yeni insanları tanıyarak, yeni bir şehir hatta yeni bir ülke, mutlu, heyecanlı günler demek oldu. Yapılan sunumların kalitesi zaten gerçekten son zirve. Katılınması itina ile tavsiye edilir :)

Red Hat'te Linux Çekirdeği Geliştiriciliği

Geçtiğimiz kış Outreachy'de Linux çekirdeği üzerinde, Red Hat'te çalışan Rik van Riel'in danışmanlığında staj yaptım.

Staj bitiminde Rik istersen Red Hat'te birkaç pozisyona başvur, ileride seninle birlikte çalışmak isterim dedi. Aslında birkaç sene daha Türkiye'de kalma kararımı Google görüşmesinden sonra vermiştim ama Red Hat'te çalışma düşüncesi de geri çevirilemez bir şeydi, o yüzden kabul ettim.

İlk önce jobs.redhat.com adresinde ilgimi çekebilecek olan işlere baktım. Rik deneyimli çalışan aradıklarını söyleseler bile, yeni başlayan pozisyonunda da iş bulabiliriz dedi. Open Stack, Sanallaştırma ve Arm işlemciler için çekirdek geliştirimi olarak 3 farklı pozisyona başvurdum. Bu üç pozisyon üzerinde de hiç deneyimim yok ancak daha uygun pozisyonlar bulamadım. Zaten onlar da deneyimi olmayan eleman alacaklarını biliyorlardı.

Open Stack ekibi İstanbul'dan taşınman gerekir, bu gibi durumlarda deneyimsiz geliştriciler yerine kıdemli olanları tercih ediyoruz ama sen şansını deneyip mülakatlara gir dedi. Sonrasında kıdemli elemana daha çok ihtiyaçları olduğunu belirttiler, diğer görüşmeleri yapmadık.

Sanallaştırma ekibi aynı zamanda Rik'in çalıştığı ekip. KVM ve Qemu'yu geliştiriyorlar. Sanallaştırma pozisyonu için öncelikle başlangıç görüşmesi yaptık. 2 hafta sonrasına gün belirleyip ilk mülakata girdim. En fazla teknik soruyu ilk mülakatta aldım, sorular zor değildi. Glassador'dan okuduğum kadarıyla Red Hat için soruları zor olmuyor yazıyordu. İlk görüşmede spinlock, zamanlama gibi temel çekirdek kavramlarından sordu. Yeni bir konu olsa da gerçek zamanlı algoritmalar üzerinde yorum yapmamı istedi. Üniversitede en sevdiğim dersler, staj projemde neler yaptığım, bir yamayı kabul ettirene kadar en fazla kaç sürüm gönderdiğim, stajda kabul edilen yamaların çekirdeğin kaçıncı sürümünde olduğu, Rik'le nasıl çalıştığım, kodlamaya nasıl başladığım .. şeklinde devam eden staj sürecimin her evresinden sorular aldım. Görüşme sonunda bir sonraki adıma geçtiğimi öğrendim \0/.

Sonraki adım 5 farklı mühendisle görüşmeyi içeren bir paket gibi. Bu görüşmelerin hepsi aynı günde olmak zorunda değil ve her biri yaklaşık 50 dk sürüyor.

Red Hat görüşmeleri Google'ınki kadar zor değil ve görüşme zamanlarını istediğimiz kadar geniş bir süreye yayamıyoruz. İki görüşme arasındaki süreyi Google pek önemsemezken, Red Hat'teki arkadaş senin yerine başka birini işe alabilirler, bu yüzden görüşmelere ne kadar erken girsen o kadar iyi demişti.

Diğer görüşmeler çok az teknik soru içeriyordu. Genelde stajda neler yaptığım üzerine konuştuk. Bir gün iki görüşmeye birden girdim. O akşam pek yorucuydu diyebilirim. Birde Google görüşmelerinde bu kadar heyecanlanmadım. Sanırım 3. görüşmeden sonra normal heyecanda konuşabildim.

Son görüşmeyi Rik'in içinde bulunduğu takımın yöneticisi olan bir kadınla yaptık. Tüm görüşmeler içindeki tek kadındı. Görüşebileceğim en yüksek mercideki kişiydi.

Son görüşme çok eğlenceli geçti. Bir iş görüşmesinden ziyade bir arkadaşımla konuşuyormuşum gibiydi. Teknik sorular yok denecek kadar azdı. Çanakkale'den, şimdiki işimden, neden çekirdek üzerinde çalıştığımdan, Türkiye'den taşınma durumumdan konuştuk.

Bu görüşmeden bir iki hafta sonra Red Hat'te işe alındığımı öğrendim, Brno'da çekirdek geliştiricisi olarak çalışacaktım.

Birkaç aydır pek iyi değildim, rahatsızlığım zirveye ulaştığında doktora gittim. Şimdilik çok ciddi bir rahatsızlığım yok ancak İstanbul'dan taşınmaya yetecek kadar da iyi değilim, ülkeyi değiştirmek zaten zor bir durum .. Ben bu kararsızlıklar içerisindeyken Red Hat'e de bunu söyledim, taşınmam 4 ay sürer, ben birkaç ay daha geciktirsem gitmeyi derken Red Hat'ten gelen maaş teklifi çok az oldu. Birde taşınma masraflarını zaten karşılamıyorlar. Bir iki firmadan duyduğum kadarıyla taşınma konusunda çok yardımcı olan yerler de var ..

Brno netten gördüğüm kadarıyla pahalı bir yer değil, ancak Red Hat'in €1k'nın biraz altında maaş teklif etmesine şaşırdım. Mezuniyetten sonra bir seneye yakın bir zaman evden çalıştım ve bu zamanı çok da fazla karşılık almayarak geçirdim. Başarılı projelere bu şekilde katkı vermek bir süreliğine benim için kabul edilebilir bir şey. Ancak bunu yurtdışındayken ve sağlığım da şuan için çok iyi değilken kabul etmedim.

Aslında Red Hat kabul etmediğimde evden çalışmayı teklif etti, kabul ettim ancak sonrasında yeni başlayanların bir sene boyunca ofiste çalışması gerektiğini ve ilk yıldan sonra evden çalışma izinlerinin olduğunu söyledi. Neticede maaş ve rahatsızlığım nedeniyle kabul etmemiş oldum. İk'daki arkadaşa Brno'da çalışmayı İstanbul'da birkaç sene çalıştıktan sonra olsaydı kabul ederdim, dedim. Daha sonraki bir zamanda eğer çalışmak istersem kendisiyle iletişime geçmemi istedi.

Bugünlerde kendime iyi bakıp, daha sağlıklı yaşayarak hayatımı düzene oturtmaya çalışıyorum. Zaten öğrenciyken de yaşama şeklimi değiştireceğim diyerek kendime bu sözü vermiştim. Ben bu sözü tutmaya başlamadan önce, vücudum bana uyarıyı verdi :p. Aslında çok önemli şeyler değil ama çok geç saatlere kadar uyanık kalmamak, az tuzlu yemek, sağlıklı beslenmeye çalışmak gibi okul temposundan sonra daha normal koşullarda çalışmayı düşünüyorum :).

Yurtdışına yine giderim, sonraki zamanlarda karşıma daha iyi koşullarda başka fırsatlar çıkar diye ümit ediyorum.

Linux Stajı Sonucunda

12 Mart sonunda Outreachy (OPW) kış dönemi stajları sona erdi. Ben bu süreçte bellek yönetiminde, THP (transparent huge page) kodları üzerinde çalıştım. Birlikte çalıştığım danışmanımın istersen bir süre daha birlikte çalışmaya devam edebiliriz demesiyle şimdi hala devam ediyorum :).

Staj sürecinde sadece okunur sayfalar, sıfır içerikli sayfalar (zero page, bellekte henüz eşleme yapılmamış sadece okuma isteği almış ve veri içermeyen sayfa) ve swap cache üzerinde çalıştım. Swapteki veriler için birini stajdayken diğeri stajdan sonra olmak üzere iki yama hazırladım. İkisininde ortak yanı do_swap_page kısmında takılıyor olmaları ^_^. Sistem bazen askıda kalıyor, bazen boot aşamasında bile bir panik oluyor gibi problemleri var hala. Koddaki sayaçların değerini daha iyi görebilmek için tracepoint yazdım. Tracepointi de ayrı bir yama olarak göndereceğiz. Askıda kalma problemleri için en iyi yöntemler ise serial console ya da netconsole kullanmak. Geçen gün Sarah Sharp'ın günlüğüne bakarken burada bir netconsole yazısı gördüm :). Askıda kalma olayı genelde spinlocklarda bir hata yaptıysak oluşuyor.

Outreachy'de, Linux Vakfı kendi stajerlerini 5 dakikalık kısa konuşma yapmak için Linuxcon'a davet ediyor. Ben Dublin'de olana katılacağım, Seattle'da olan biraz fazla uzak. Zaten bu ara hangi etkinliğe gitmek istesem hep Dublin'e denk geliyor, aslında ben mümkün olduğunca başka şehirler seçmeye çalışıyorum :).

Nisan başında lwn.net'te stajımla ilgili bir yazı yayınlayacaktık, yazının taslağı hazır, sanırım swaplerle olan işler bittikten sonra onları da ekleyip yayınlayacağız.

Bu staja alınmam benim için biraz sürpriz gibi oldu. Necdet hocanın hadi Ebru başvursana demesiyle başvurdum ve çok iyi oldu, çok da güzel oldu :).

Mezuniyetimden beri evden çalışıyorum, bu biraz değişik oldu. Muhtemelen bir ay daha evdeyim, sonra bir süre çekirdeğe ara verip başka işlere bakıp, sonrasında tekrar döneceğim :). Çekirdek üzerinde çalışmanın diğer alanlara göre daha fazla dikkat gerektirdiğini düşünüyorum. Çünkü bir yerde hata yaparsam o değişikliği geri almak daha uzun sürüyor, daha fazla şeyi kontrol etmem gerekiyor.

Staj sürecimde işini çok iyi yapan insanlarla birlikte çalıştım. Rik, 12 senedir Linux üzerinde çalışıyor. Bunun ilk duyduğumda bir yutkunma .. :).

Aslında üniversiteye başladığımdan beri hep işini çok iyi yapan, hayran olduğum insanlarla bir aradayım. "Harika insanlarla birlikte çalıştım" diyebilmek, bu hayattaki en güzel şeyler arasında ilk sıralarda yer alır. Çomü'de bilgi işleme gitmeye başladığımdan beri ben de bu sözü söyleyebiliyorum ve iş hayatında da böyle devam eder diye ümit ediyorum :).

Sending First Patch To Upstream

Last week, I sent first patch to upstream and it was accepted in mm tree :). I am very happy about that. You can see it here.

Subsystem maintainers are very careful and a lot of people review the codes. Out side of staging directory, and before the internship, my first patch is about y2038 project. When I sent patch for y2038, a lot of developers reviewed and suggested something. I have recently seen the patch here: http://lwn.net/Articles/620870/, it was my first experience :).

Todays, I work with linux kernel mm community, this makes me very excited and happy :).  I gained some experiences in this process and learnt how can I be sure with my changes. This is most important case for coding. When I talked with my mentor, every time I reported different thing :) and said "oh this prevents collapsing pages into a thp!". Because I was testing wrong. Finally I could find what was the problem.

For test results, I look /var/log/kern.log, it is very large file so I split it like that: "split -n 5" and look newly created small files and log time stamps is important. To be sure with my changes print out virtual memory address area for my test programs.

/proc/pid/smaps shows whole vmas for the process. pr_info("vm_start = %04lx\n", vma->vm_start); is enough to see begining address of the vma. Sometimes I need to see which process run this function, I print out current->pid. If I know what happened in every step, I find my faults very easy. I have to do something like that, because other processes will log about their huge pages in kern.log and I shouldn't confuse which process logged the results. To examining kern.log was big scale thing for me.

Before sending patch I need to be careful and check something for my patch. Also keeping focus on the issues is important. Working on kernel needs to pay attention more accorrding to other projects which I got experiences with them when I was student.

After this patch, I will work on zero pages and discover new things :).

Collapsing Huge Pages & Swap In/Out

Last week, I focused on collapsing huge pages and swap in/out. Rik  have asked me some questions and I countinue to reply them. When we study, he puts some hints to questions and sometimes, I back to old questions and try to understand them better. I've started to follow linux-mm list and understand what they mention about at least :). Before I've tried to follow some staging lists but see emails a lot* everyday.

My project includes very small coding according to other kernel internship projects but the topic is too complex and its about core functionality of Linux Kernel. That's really good :). Before the internship, I was thinking "I should pick a small staging driver and study for todo issues". Because with small driver, learning and to be part of Linux Kernel can be easier and I was going to do just self study, also work at another company so have not enough time. Todays, I study on almost hardest topic with a Linux Kernel developer!

I can start coding for my project but need to discuss which policy we will follow to get swapped out pages to memory. We should discuss about trade off to collapsing pages in a 2 mb page when getting them from swap to memory. Keeping in mind the functions is a bit hard for me, I re-look a lot of time to which function what does. My memory is not good :(.

I've replied following questions which are asked me by my mentor. When I reply the questions, don't need to search just from books, look to codes and understand a bit of them :).

Following call chains for Linux Kernel - 3.18

1) How is a page swapped out?

add_to_swap()
        get_swap_page()
                scan_swap_map()
        if(PageTransHuge(page))
                if (split_huge_page_to_list(page, list))
                        swapcache_free()
        add_to_swap_cache()

Swapped out is implemented by add_swap_page(). The function allocates swap space for a page. Swap areas includes slots, and their size are equals to page frames.

It checks whether page up to date and locked then gets swap page, get_swap_page() firstly checks is there a swap page with atomic_long_read(&nr_swap_pages) if so, decrements nr_swap_pages by one. In there used highhest_bit to decrease searching time of free slot. get_swap_page() returns type swap_entry_t. add_swap_page(), cheks whether the page is huge, if so; it splits the huge page to list with
split_huge_page_to_list(page, list).  The function calls __split_huge_page() -> __split_huge_page_map().

If split_huge_page_to_list() returns 0, that means splitted pages succesfully. After that it adds the page entry to swap cache. If huge page can not splitted then called swapcache_free(entry), to release retrieved swap page.

Note: I did not understand why we set page as dirty? at line:202. The page is not changed. Rik's answer: After the page is added to the swap, it is removed from the process page tables.

Then we have a page that is only in the page cache, and not mapped in any process. The dirty bit indicates the data has to be saved to swap before the page can be freed.

scan_swap_map() is used to find free swap slot.

2) Where is the information of where a page is in swap, stored in the data structures used to track the memory of a process?  In other words, how does swap in find where in swap memory is?

Using swap_info_struct swap_info[] array, it includes indexes of ptes and also offsets are stored in swap_map.

3) How is a page swapped in?
do_swap_page()
        pte_to_swp_entry()
        lookup_swap_cache()
        if (!page)
                swapin_readahead()

        else if (PageHWPoison(page)) {...}

It calls pte_to_swp_entry(), pte is converted to swap entry. the function converts pte to architecture independent entry format. Then checks validation of entry with non_swap_entry(). Sets DELAYACCT_PF_SWAPIN flag to spcefiy that does in swap operation. It checks whether the page in swap cache. If so, checks HWPoison flag which is for recovering memory errors; if not runs swapin_readahead() to get probably needs to swap in pages. If HWPoison is setted, it goes to label out_release and release the page and swap cache page from page cache. I've a question here: if the page was huge, but right now it is not because splitted to locate on swap. The page have no compound flag anymore? Is that correct?

Rik's answer: Swap only ever stores single pages, indeed. That means swapped
in pages will not have the compound flag set page_cache_release() calls put_page(), and the function checks using PageCompound().

Note: do_swap_page() gets two pte argument. orig_pte is created by handle_mm_fault() using ACCESS_ONCE(). The macro is for volatile issues maybe but I didn't understand why second pte is created.

Answer: do_swap_page gets both the location of the pte (a pointer) and the value of the pte at handle_mm_fault time. This way it can verify whether the pte changed from its original value, while it is doing things (like retrieving data from swap)

4) How can you discover whether a page is present in the swap cache?

_PAGE_FILE detects whether the page in swap cache, it is into page table entry.

5) Under what conditions are 4kB pages collapsed into a 2MB THP?

In handle_pte_fault(), at line: 3219 do_swap_page() is called because system want to swapped in pages, so it wants to collapse the pages but it can't. This happens, if the cases occur: pte shouldn't be on memory and swap cache. Also pte should be belong to anonymous page, not to file.

Rik's question: Can you write down the call traces that contain the collapse functions in mm/huge_memory.c?
My answer, there are two cases for it:
do_huge_pmd_anonymous_page() -> alloc_hugepage_vma() -> .. __alloc_pages_nodemask()

khugepaged_scan_pmd() -> collapse_huge_page() -> khugepaged_alloc_page() -> alloc_pages_exact_node() -> .. -> __alloc_pages_nodemask()

Rik's answer: Firt call chain, you can leave alone during your project, and is important to understand what the data structures look like.

Second call chain: This is the one you will want to work with.

6) how many pages would be good to bring into swap when trying to collapse a huge page? how many is too much?

x86 systems use 4kB page size. It can be enlarged maximum 4mb. With 2mb page, it is enlarged 512 times, thats good. 4mb page means 1024 times enlarged, it is not so good, if size is more than 4mb huge page, it will be useless.

Rik's answer: Sure, but if all of them are swapped out, it is obviously a bad
idea to bring them all into memory just to collapse them into a 2MB THP.

Out of the 512 pages, what would be a reasonable number to not be in memory already, and bring in from swap? 1? 5? 10? 20? What would the number depend on?

My answer: do_swap_page() ->  swapin_readahead() -> swapin_nr_pages()

In swapin_nr_pages(), using page_cluster it detects how many pages getting swap in.

page_cluster defined in swap.c. swap_setup() function assigns its default value.

7) what about pages that are already in the swap cache? how should we count those?

For this question, I'm a bit confused, thought swap cache is a swap slot .. and replied different thing :). Firstly, I've tried to count how many pages in swap, afterwards go ahead to correct intent.

If a page in the swap cache, that means the page up to date on memory. Also the page is on the one swap slot. Swap cache size is equal to a swap slot. struct swap_info_struct, it has array swap_map.

I've read from book, swap_duplicate() increases slot usagecounter, probably it mentions about the line:

count = p->swap_map[offset];

I've seen on comment line of the function "increment its swap map count." So I guess, swap_map count can be slot usage counter. But I know swap_info struct per swap area not per swap slot. A swap area can include set of slots, so I think, swap_map count doesn't mean swap cache usage counter. Did I misunderstand? Can you inform me about swap_map?

Rik's answer: The swap_map counter means the number of users of that swap slot, which may be different from the number of users of the swap cache page.

However, this line of research is tangential to your project, and your interpretation of question 2 differs from my intent.

My answer: I've thought, when a page will be added to swap cache, it increases count of swap cache page.

add_to_swap_cache() -> __add_to_swap_cache()

In __add_to_swap_cache(), after adding radix tree, it increases the counter at line 104:
address_space->nrpages++;

nrpages specify total number of pages in address_space which stores swap cache address that means how many pages are in swap cache.

8) what about the !pte_write test in __collapse_huge_page_isolate? how can that break collapsing of a THP? is there a simple way to improve that?

pte_present() checks whether the entry have write access. It needs to create a page using page table entry with vm_normal_page(). If write access is disallowed, can't create page.

My mentor said __collapse_huge_page_isolate() is important point your project, and I've reviewed it:

__collapse_huge_page_isolate()
        for (_pte = pte; _pte < pte+HPAGE_PMD_NR; _pte++, address += PAGE_SIZE) {
                pte_none()
                !pte_present() || !pte_write()
                isolate_lru_page(page)

For loop:
Firstly, it checks pte_none(), this function returns true if pte is not in Ram. There is a counter none, checks with none for allowed khugepaged_max_ptes_none. If exceeds the limit then goes to label out. pte_none() returns true if none of the bits in the pte are set, that is the pte is all zeroes. pte_present() also is used for page swapped out. pte_write() checks whether the kernel write to page. Then checks is the page compound, if so does system halt. If page is not anon nor swap backed then does system halt. The page should have only one reference, this property checked by _count variable. Then it locks the page.

I'm looking isolate_lru_page(), Lru list includes inactive file/page, active file/page. But I didn't understand why there is PG_lru flag and we check it with PageLRU(page) at line 1344, vmscan.c

Rik's answer: If the page is not currently on an LRU, a different task may have that page on a pagevec, and do something with it later. That could race with trying to collapse the hugepage, and cause all sorts of problems.

In isolate_lru_page(), it checks again VM_BUG_ONE(!page_count(page), page), but already it checked for page_count() before calling isolate_lru_page() line at: 2171. Why it does this again?

Rik's answer: The page_count check is debugging code, in case somebody changes the kernel and calls isolate_lru_page on a page that got freed. It checks PageLRU once outside the lock (it can be changed by another CPU), and once inside the lock (taking a lock is expensive, and only done conditionally).

And also it checks PageLRU two times, in isolate_lru_page(). It gets lruvec then runs page_lru(), which checks page unevictable, if so sets lru as unevictable; if not, calls page_lru_base_type(), this decides base type for page - file or anon after adds active property and returns lru. Then isolate function runs get_page(), if page head or normal, increments _count. Then clear page lru and calls del_page_from_lru_list(), this function deletes lru from page using list_del()

It checks for page young conditions, then set referenced as 1. If it goes to label out, it runs release_pte_pages().

Note: That function gets a pointer to the start of a page table page, and iterates over all the ptes inside that page table page. A 2MB THP contains 512 4kB pages, which is 1<<HPAGE_PMD_ORDER pages.

Begining to Read Memory Management Codes

My Linux Kernel internship started two weeks ago and will take 3 months. My mentor is Rik Van Riel. My project aim to fix transparent huge page swapping issues, if system needs to swap huge pages, it has to split the pages to small sized ones but then the system can not reconstitute the huge pages.

Rik asked me some questions about huge page and swapping and I've replied them. Before the reply the questions I've looked for following data structures and definitions.

Firstly I've started to examine struct page and mm_struct in mm_types.h. The kernel holds all information in mm_struct, it includes vm_area_struct *mmap which involves list of memory areas.  vm_areas_struct is an object to show memory areas. Also, the kernel threads don't use mm_struct so if you see if (!mm) {...} it means this is  kernel thread.

Likely & Unlikely Functions: Theese are for branch prediction so used for compiler optimization. They supply to guess which instruction will run and do read ahead.
http://kernelnewbies.org/FAQ/LikelyUnlikely
http://stackoverflow.com/questions/109710/likely-unlikely-macros-in-the-linux-kernel

Numa & Uma Systems: I've understood the two keywords looking the picture :).

Hot &  Cold Page: If a page in cpu cache, it is hot page however cold page is vice versa.

struct scan_control: It is used for page scaning, holds following variables:
unsigned long nr_scanned: How many inactive pages were scanned.
int may_writepage: It determines whether the kernel can write backing store.
swap_cluster_max: It is restriction for a lru list.

struct zone: The kernel divides memory to nodes, and the nodes include zone lists. Every zone area include pages. You can look for struct zone.

struct list_head: Doubly linked list, to build & manage lists.

Page Flags: http://lxr.free-electrons.com/source/include/linux/page-flags.h

High Memory: Linux Kernel seperate high rate of memory for user space so high memory means user space.
http://unix.stackexchange.com/questions/4929/what-are-high-memory-and-low-memory-on-linux

Page Vector: Provides operations on page list instead of individual pages.

Slot: Swap area is divided to slots. Size of each slot equals to page frame.

up_read/write, down_read/write functions: They are for spinlock issues and includes assembly instructions.

BUG_ON* functions: Checks given condition and returns system halt or nothing.
http://lxr.free-electrons.com/source/include/linux/mmdebug.h#L18

Swap Cache: Some pages after swapped out, if the page is not changed, it has an entry on swap cache and system can read data on memory withouth get the page to back memory.
http://www.linux-tutorial.info/modules.php?name=MContent&pageid=314

Transparent Huge Page vs. Huge Page: Transparent huge page supplies a layer for huge page. http://goo.gl/qGksYX

Note-1: Swap space used by user space tools (mkswap)

Note-2: x86 systems don't use pte level for THP (transparent huge page), it can direct access data on pmd.

Following questions which are asked to me by my mentor. I've explained just important points for my project and their function traces because there are a lot of functions, sometimes they can be very complex :).

Below call chains for Linux Kernel - 3.18

1) from do_page_fault(), sometimes the VM uses transparent huge pages
   (2MB size on x86) for anonymous memory. What functions does the
   code go through between do_page_fault() and the function that
   installs 2MB pages in the process page tables?
When I examined functions, I saw a lot of spinlock functions and Rik said, they for ensure that multiple concurrent instances of the page fault code do not manipulate the page table simultaneously.

do_page_fault()
  __do_page_fault() /* checks the fault is belong to bad area or good area */
    handle_mm_fault()
      __handle_mm_fault()
        __do_huge_pmd_anonymous_page()
       
         
pgtable_trans_huge_withdraw takes a page table page from the process's
reserve of page table pages, so the 2MB page (mapped at pmd level) can
be mapped as 4kB page entries (at the pte level).

2) When are 2MB pages used?
If PAE is enabled, then use 2mb pages. I've looked for it following links:
http://en.wikipedia.org/wiki/Physical_Address_Extension https://www.cs.rutgers.edu/~pxk/416/notes/09a-paging.html
http://en.wikipedia.org/wiki/Page_Size_Extension
http://en.wikipedia.org/wiki/Page_%28computer_memory%29#Huge_pages

3) What does the VM do when a 2MB page cannot be allocated?
   (still in memory.c and huge_memory.c)
In  do_huge_pmd_anonymous_page(), if it can not allocate 2MB page;
it returns, out of memory or fall back. It also calls count_vm_event()
with THP_FAULT_FALLBACK argument. At line: 824, it tries to set
huge zero page, if it can't do that, calls put_huge_zero_page(),
which calls atomic_dec_and_test(). 

At line: 839: If it couldn't install huge page, it calls
put_page(). I've thought;in put_page, it checks whether
the page compound or not, but the page will be compound
always, because the page comes from alloc_hugepage_vma().

4) When the system runs low on memory and wants to swap something
   out, it will split up a huge page before assigning it space in
   a swap area. Find the code in vmscan.c, swapfile.c and huge_memory.c
   that does that. What does the function trace look like from
   try_to_free_pages to the function that splits the huge pages?
try_to_free_pages()
  throttle_direct_reclaim(gfp_mask, zonelist, nodemask)
    do_try_to_free_pages(zonelist, &sc)
      delayacct_freepages_start()
      global_reclaim()
      do while { vmpressure_prio()
      shrink_zones() /* if a zone reclaimable it returns true */}

I've seperated shrink_zones() to below:

shrink_zones()
  nodes_clear(shrink.nodes_to_scan)
  loop:
  populated_zone() {return (!!zone->present_pages);}
  zone_reclaimable_pages(zone) -> get_nr_swap_pages()
  node_set()
  zone_reclaimable()
  shrink_zone()
     shrink_lruvec()
       shrink_list()
          shrink_active_list()
          shrink_inactive_list()
             shrink_page_list()
               add_to_swap()
                 split_huge_page_to_list()
                    __split_huge_page()
                       __split_huge_page_map()

try_to_free_pages(): If memory is not sufficent, it checks pages and removes least used one.
shrink_zones(): It is runned by kswapd with specified time interval and used for remove rarely used
pages. It also balances inactive and active lists using shrink_active_list().
shrink_active_list(): Provides to transfer pages between active_list and inactive_list and detect least used active lists and also implements page selection.
shrink_inactive_list(): Removes lists from inactive_list and send the lists to shrink_page_list().

In general, shrink_* functions run per zone.

5) in huge_memory.c look at collapse_huge_page and the functions
   that call it - under what conditions does the kernel gather up
   512 4kB pages and collapse them into one 2MB page?
collapse_huge_page()
                khugepaged_alloc_page() /* allocate new page */
                __collapse_huge_page_isolate(vma, address, pte); /* this one is new function for me */
                if (isolate_lru_page(page)) { ... }
                if (pte_young(pteval) || PageReferenced(page) ||
                        mmu_notifier_test_young(vma->vm_mm, address)) { ... }
                __collapse_huge_page_copy()

collapse_huge_page_isolate() removes pages from lru with isolate_lru_page().
I've thought: when collapsing pages, their lru's will change. So it isolates
pages.

Note-1: __collapse_huge_page_copy(): The 4kB pages could be anywhere in memory.
The 2MB page needs to be one contiguous page.
That means the contents of the 4kB pages need
to be copied over into the one 2MB page.
khugepaged_scan_pmd(), if page is young, it will call collapse_huge_page().
If the collapse function can correct vma, pmd and isolate pages, it collapses
pages.

6) under what conditions does the kernel decide not to collapse
   the 4kB pages in a 2MB area into a 2MB page?
There some conditions for it:
1) If can't alloc khuge page, it won't collapse.
2) I've looked to this condition in collapse_huge_page():
        if (unlikely(khugepaged_test_exit(mm))) {goto out;}
   if mm has no user, it goes to label out and doesn't collapse pages.
3) If it can't find vma and pmd
4) If it can't isolate pages

7)  look at what happens when shrink_page_list()
passes a 2MB transparent huge page to add_to_swap()

When it sent 2 MB page to add_to_swap function, it firstly checks whether page locked and up to date then calls get_swap_page(). If there is no swap page returns 0, If not it checks transHugePAge() then implements split_huge_page_to_list(). In split_huge_page_to_list it gets anonymous vma and does write-lock for it and checks PageCompound. With PageCompound it controls the is huge or not.  Then it checks PageSwapBacked. Then calls __split_huge_page() and the function wants the page shouldn't be tail and splits the page in __split_huge_page_splitting(). The function backs to add_to_swap and does swapcache_free() issues.

8) Can you explains what the page looks like after it has been split?

What happened to the 2MB page?  What do we have instead?

What happened with the PageCompound flag?

__split_huge_page(), it calls __split_huge_page_splitting() in the iteration. It counts number of mapped pmds before splitted it and increase mapcount.

In split_huge_page_map(), it takes page offset with address argument. Firstly, it checks pmd address validity. It

creates small entries in for loop with mk_pte(), set_pte_at(), pte_unmap (this one is just nop instruction for x86 systems). The for loop does one entry for page one, then page two, then page three etc. It changes address of entry adding pagesize (haddr += PAGE_SIZE) up to number of pmd.

I've asked, why pmd_populate()  is performed two times at lines: 1790, 1843?

Rik's answer: The first pmd_populate puts in place a special transparent huge page

PMD that says "this transparent hugepage is being split, do not mess
with it".

The second pmd_populate puts in place the page table page containing
the 4kB pages that map the 2MB area.

Note-1: In __split_huge_page() iterates vma from root of red black tree at line: 1864 but the function gets only one page and a page can match just one vma. So why it needs to iterate vma?

Rik replied my question: "The same page may be shared by multiple processes, if the

process that created the 2MB page originally called fork() afterwards."

Note-2: In  __split_huge_page_splitting(), it calls  pmdp_splitting_flush() what does it do also pmd_update and flush_tlb_range function? I think it should save pmd's content before splitting, it shouldn't lose it. Why it flushes pmd?

Rik's answer: if a small page is touched or dirtied afterwards, we want the MMU to set the accessed and/or dirty bit on the 4kB page entry.

Note-3: We can ignore PVOP_VCALL stuff - that is for Xen, which uses an alternate function for filling in page table info. 

9) Under what conditions can a region with 4kB pages be
turned into a 2MB transparent huge page?
I've traced following call chain:
do_page_fault()
        __do_page_fault()
                handle_mm_fault()
                        __handle_mm_fault() /* check conditions */
                                do_huge_pmd_anonymous_page() /* check conditions */
                                __do_huge_pmd_anonymous_page() /* check conditions */

In __handle_mm_fault(), "if (pmd_none(*pmd) && transparent_hugepage_enabled(vma)) { ... }" if the expression is correct, it can realize do_huge_pmd_anonymous_page(). I've seen this quote for pmd_none() "if page is not in RAM, returns true." But I think, if page is not used for any process, it includes zeros and should be in RAM.

In do_huge_pmd_anonymous_page(), "if (!(flags & FAULT_FLAG_WRITE) && transparent_hugepage_use_zero_page()) { ... }"
if it can correct the condition, it can start to create transparet huge page. I've looked for condition values.
flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE; allow retry and killable flag values are defined with special values (0x08, 0x02)?
I think their values only for to check something. And transparent_hugepage_flags is 0UL, is it always have this value? I've looked for its value,
probably always have same value. The last condition creates huge zero page using  set_huge_zero_page() which calls pmd_mkhuge().

One more condition: __do_huge_pmd_anonymous_page(mm, vma, haddr, pmd, page), if it returns false, that means created transparent huge page at line: huge_memory.c#L808
If pmd_none() returns true, creates thp.

10) What code turns 4kB pages into a 2MB page?
pmd_mkhuge() installs 2 MB page. Actually, it does pmd_set_flags(pmd, _PAGE_PSE).
_PAGE_PSE uses _PAGE_BIT_PSE which means huge page.

11) Under what conditions can a region with 4kB pages not
be turned into a 2MB transparent huge page?
There are a lot conditions for this.

1) If the entire 2MB page inside vma, return fall back.
2) If it can't create anonymous vma, return out of memory.
3) If it can't create huge page vma, return fall back.
4) If it get true from __do_huge_pmd_anonymous_page(), return fall back.
5) in __do_huge_pmd_anonymous_page(), if page is not support huge page, the code create kernel panic, and halt.
   VM_BUG_ON_PAGE(!PageCompound(page), page);
6)  If it cannot allocate a huge page

Linux Kernel Internship

Last month I've applied Gnome Outreach Program for Women and sent patches for Linux Kernel. I've applied it because wanted to learn low level things. I also really like computer design and architecture topics. Actually, I have not enough knowledge about them but like to learn them.

Linux Kernel Community accepted to me as an intern. I'll study on Khugepaged swap readahead project. Working with Linux Kernel team will be great experience for me. They really want to help kernel newbies :).

Actually, studying on Linux Kernel needs a lot reading. Just for writing a few code lines needs to read one chapter from one book, a few blog posts about topic and ask something to developers :).

Nowadays, I've started to read about memory management issues like TLB, Huge Pages, Page Fault from one operating system book and also examine do_page_fault() function.

Yeni Başlayanlar İçin Linux Kernel Araçları

Yorucu bir vize haftasının ardından tekrar kendimi geliştirmek için çalıştığım şeylere devam ediyorum. Aslında devam etmeye çalışıyorum çünkü gerçekten çok yorulmuşum :(. Bir de son sınıf olunca sanırım insan kendini daha çok yorulmuş hissediyor.

Linux Kernel için okuduğum şeylere devam ediyorum. Bugünlerde çekirdek geliştiricisi olmanın ne kadar güç bir şey olduğunu anlamam konusunda zirveye ulaşıyorum. Linux Kernel'a yeni başlayanlar için hazırlanan sitelerde hep bu resmin olması da bana bir işaret olabilir :)

Elbette çekirdek geliştiriciliğinin kolay bir şey olmadığının herkes gibi biliyorum. Ancak okuduğum bir yazıyı anlamak için bir kaç kere okumak, her belgenin çok uzun olması, bir çok satırda ne söylenilmek istenildiğini tam anlayamayıp on tane daha yere bakmak biraz yorucu. Bir de hatanın hangi durumlarda oluştuğunu anlayıp, o kod içerisinde oluştuğunu anlayamamak bir problem. Örneğin paylaşımlı veri yapıları ile ilgili problemleri çözebiliriz ancak o veri yapısı paylaşımlı mı nasıl anlayacağız :) gibi.

Aslında geliştiricilik olmasa bile daha güzel katkılar vermek istiyorum. Çünkü çalıştığım ilk bir ayda checkpatch.pl, sparse ve çok az coccinelle kullandım. Bunlar statik ve en temel araçlar.

checkpatch.pl ile gönderilen yamalar geliştiricilerin de okumaktan biraz sıkıldığı yamalar. Sparse ise derleme sırasında hata vermeyen ancak statik yazılım denetimi yapan ve Torvalds tarafından başlatılan bir proje. 

Coccinelle ise tüm bunlardan daha farklı. Kendine özel Smpl (Semantic Patch Languange) ile yazılan anlamsal betiklerden oluşuyor. Cocci kullanırken kendimiz bir hata tipi seçiyoruz. Bu hata tipi sparse, checkpatch.pl ya da başka bir araçla alınan ya da kendi belirlediğimiz bir hata tipi olabilir. Sparse hatalarını .cocci betikleriyle düzeltmek zor. Çünkü Sparse hatalarını çözmek için tek bir standart yok ancak checkpatch.pl öyle değil. Belirlediğimiz bu hata tipi için genelde formal diller adı altında geçen statement, expression, identifier gibi kavramlarla bir şablon oluşturuyoruz. Bu hatanın çözümü için ise yine kendimiz başka bir şablon oluşturuyoruz. Aslında betikte hem hatayı hem de çözümü bir şablon halinde belirtmiş oluyoruz.

Çalıştığım bir aylık süreçte bu üç aracı öğrendim diyebilirim. Bir de smatch var ama ben kendisini hiç kullanmadım :) Bugünlerde ise modüller için dinamik test etme araçlarına bakmaya karar verdim. Hangi araçlar olduğu ve nasıl kullanıldıkları hakkında henüz bir fikrim yok :) ama standart olarak hiç fikrimin olmadığı şeylere en baştan bakıyorum. Bir de çekirdek geliştiricileri çok yoğun olduklarından çok fazla cevap atmıyorlar listelerde ya da irc'de. Bir de sanırım bu kural gibi, sana verilen bir işi listelerde sormadan kendin yapmalısın.

Geçen gün Linux Kernel katkıcısı olmak için düzenlenen Eudyptula Challenge sürecini gördüm. Aslında ortada bir challange yok :) Kendimiz basitten karmaşığa driver yazmaya başlıyoruz. Bu süreçte de her işi kendin yapmalısın ve listelerde ya da irc'de sormayın diye kesin bir şekilde belirtmişler. Bu Opw için de geçerli miydi bilmiyorum. 

Önümüzdeki günlerde Muğla ve Eskişehir'de sunum yapacağım. Döndükten sonra Linux Kernel ile ilgili okuduğum şeylere devam etmeyi ve Sparse, Cocci kullanımının nasıl olduğunu burada yazmayı düşünüyorum.

Linux Çekirdeğine Nasıl Katkı Verilir?

Gnome'un düzenlemiş olduğu Outreach for Women etkinliğine başvuru süreci 11 Kasım'da bitiyor. Ben bu süreçte Linux Kernel için hazırlandım. Geçen yıl Gnome'un kendi araçlarına başvuruyordum ama sürekli bir şeyler derlemek, kütüphane sürümlerini uyuşturmaya çalışmak bir miktar sıkıcı olabiliyor. Bunun için jhbuild ya da Fedora'nın bir sonraki, henüz çıkmamış sürümünü kullanmak tavsiye ediliyor :) Çünkü katkı vereceğimiz Gnome aracının depodaki son hali üzerine değişiklik yapmalıyız. Çekirdek üzerinde çalışmanın nasıl olduğunu bilmediğimden bu sefer çekirdeğe başvurmaya karar verdim.

Opw Kernel sayfasında tüm yapılması gerekenler, okumak için önerilen bir kaç kitap var. Öncelikle örnek olarak ethernet kodu içine printk("..") ile bir şeyler yazdırıp, çıktısını dmesg logunda görmek var. Burada Greg Kroah-Hartman ilk yamanın nasıl yapılacağından bahsetmiş. Temel olarak yama göndermeye kernel.org'dan aldığımız çekirdek kodları dizini içerisindeki drivers/staging'den başlayabiliriz. Buradaki kodların yazılış biçimini düzeltmeyle işe başlayabiliriz. Greg'de linkini verdiğim sunumunda bundan bahsetmiş. Çok temel kodlama biçimi düzeltmeleri yapabileceğimiz gibi, daha karma düzeltmeler de yapabiliriz. Bir de yama gönderirken e-posta konu satırına uyarı çıktısının tam halini yazmamız gerekiyor. Kendimiz uyarıyı yorumlayıp "bu yama bunu düzeltiyor" şeklinde yazdıklarımız genelde kabul edilmeyebiliyor. Bu yüzden tekrar göndermemiz gerekiyor.

Opw Kernel'a başvurmak için bu temel yamalardan göndermek yeterli. Hatta bu yılki Opw projelerinden birisi de kodlama biçimi düzeltme ve Todo dosyalarındaki eksikleri kapatma. Todo dosyalarındaki eksikleri kapatmak biraz daha alt seviye, aslında baya bir alt seviye :). Çünkü yapılması istenenler de o kadar açık belirtilmemiş dosyada. Ben de çekirdek uyarı mesajlarını analiz etme ve iyileştirme projesine başvurdum.

Başlangıç olarak Linux Kernel'a kodlama biçimi düzeltme dışında Sparse ve Coccinelle araçlarını kullanarak katkı verebiliriz. Bu araçlarla drivers/staging altındaki kodları derlediğimizde aldığımız uyarı mesajlarına göre düzeltmeler yapabiliriz. Bir de kodlar içerisinde yer alan Fixme etiketlerinden yararlanarak katkı vermek de yapabileceğimiz seçeneklerden birisi. Katkı verirken zorlanabileceğimiz yanlardan birisi, Linux Kernel ekibi kodlama biçimine oldukça önem veriyor. Bu yüzden aynı yamayı defalarca göndermek gerekebiliyor. Hatta kodlama biçimini test etmek için yazdıkları bir Perl betiği var. Zaten kodlama biçimi düzeltme yamalarını gönderebilmek için bu betiği kullanmalıyız.

Sparse aracı ile fonksiyon tiplerinin ya da değişken tiplerinin doğruluğu, gereksiz fonksiyonları kaldırma, tip dönüşüm işlemlerinin doğruluğu gibi uyarıları analiz edebiliriz. Bu düzeltmeleri yapmak için koddaki fonksiyonları okuyup, çağırılma sıralarını kontrol etmek, kzallac, kmalloc, volatile gibi tiplere, tip dönüşümlerine bakmak gerekli. Çeşitli tiplerin ne olduğunu öğrenmek için burayı okumak faydalı olabilir.

Coccinelle aracını ise ben henüz kullanmadım. Ancak önümüzdeki günlerde onu da denemeyi düşünüyorum. Bir de daha karmaşık hataları çözebilmek için bir kitap bulup okumayı düşünüyorum.

Opw ekibi projede çalışmak için kişi seçerken genelde öğrenci olmamasını tercih ediyor :( . Okul dönemi içerisinde olan bir öğrenci seçmektense herhangi bir işte çalışmayan birisini seçmenin daha verimli olacağı düşüncesindeler. Bu yüzden öğrencilerin Opw yaz dönemine başvurunca seçilme ihtimali daha yüksek. Çünkü proje sürecinde bir işin var mı sorusuna, sınav haftalarını yazmaktansa hiç işim yok yazmak, şansımızı artıran bir etken. Eğer ben de bu dönem kabul edilmezsem, yaz dönemi tekrar başvuracağım.

Çekirdeğe Katkı Sürecinde Git Kullanımı

Git uzaktan birlikte çalışmak için oldukça yetenekli bir araç. Bu dönem Linux Kernel'a katkı verirken git'in daha fazla özelliğini kullanmam gerekti. Çünkü çok fazla kişinin sürekli aynı dosyalar üzerinde değişiklik yapıyor olması durumunda daha gelişmiş bir biçimde sürüm takip sistemi kullanmak gerekiyor.

git-send-mail

Tarayıcı üzerinden yamayı mail gövdesine kopyaladığımızda girintilerde kaymalar, satırlarda kaymalar meydana gelebilir. Bunun için yama dosyasını e-postada ek olarak göndermeliyiz, ya da git-send-mail ile göndermeliyiz. git-send-mail için temel bir kaç ayar gerekli, bu ayarları her seferinde yeniden girmemek için yapılandırma dosyasına yazabiliriz. Ev dizinimizdeki .gitconfig dosyası için gerekli olan ayarları ben buradan örnek alarak ayarlamıştım

git-rebase

Yerelimdeki Linux Kernel deposuyla uzaktaki depoyu senkron tutmam gerekti. Opw Kernel sayfasında bahsedildiği gibi depomda değişiklikler yaptım. Bunun için öncelikle "git remote add" diyerek "staging" adı altında depoyu izlediğim depolar arasına ekledim. Bu şekilde depo ekleyip, deponun istediğimiz dallarını çekebiliriz. Daha sonra "git rebase staging/staging-next" ile rebase işlemini tamamlamış oluyoruz.

Aslında burada aklıma takılan "merge" kullanarak da bir çok şeyi halledemez miyiz, olmuştu. Ancak merge kullandığımızda aynı depo üzerinde çalışan herkesin, her şeyi kusursuz yapmış olmasını beklemek gerekir. Eğer küçük bir ekiple çalışıyorsak "merge" yeterli oluyor. 

git-rebase ile aynı zamanda commit tarihimizi değiştirebiliriz, eskiden yaptığımız bir committeki değişiklikleri düzenleyebiliriz. Bunun için "git rebase --interacative commit_id" diyoruz. Bu şekilde rebase etme sürecini başlatabiliriz.

Eğer son yaptığımız committe bir değişiklik yapacaksak "git commit --amend" olarak kullanabiliriz, ancak son committen daha eski commitler üzerinde oynamak için "git rebase --interactive" kullanmalıyız. Daha sonra karşımıza çıkan editörde commit mesajını değiştirmek istediğimiz commitin başındaki "pick" ifadesini "edit" olarak değiştirmeliyiz. Daha sonra "git commit --amend" kullanıp, commit mesajını değiştirmeye başlayabiliriz. Son olarak "git rebase --continue" ile commit mesajı değiştirme sürecini bitirmiş oluruz.

Üzerinde oynadığım büyük bir dosyada 9 tane commit yapmıştım ve bu commitlerde yaptığım değişikliklerin arasından 4-5 tanesini düzeltmem gerekti. Son değişikliklerde öncekilere bağlı olduğundan, dosyanın son hali üzerinden tekrar düzeltip göndersem, dosyanın depodaki orjinali bu değil diye geliştiriciler kabul etmiyorlar. Bu durumda eğer 5. commit değişmeliyse, dosyanın 5. committeki hali üzerinden düzeltmek gerekli. Ya da tüm yama serisini baştan hazırlamalıyız ki, bu zorlaştıran bir iş.

Bu yüzden git rebase'i kullanıp, edit şeklinde committi seçiyoruz. Daha sonra değişiklikleri yapıp "git add üzerinde_çalıştığımız_dosya" ve "git rebase --continue" şeklinde bu işlemi bitirebiliriz. "--continue" parametresini rebase ile yapacağımız değişiklikler bittikten sonra kullanmalıyız.

edit, dışında bir de "squash" ile yaptığımız commitleri birleştirebiliriz. Eğer altı kere değişiklik yapıp bunları hepsini ayrı ayrı commitlediysek format-patch ile oluşturacağımız yamalarda altı parçadan oluşacak. Eğer bunların hepsini tek bir commit mesajı altında birleştirmek istiyorsak "pick" yerine "squash" yazarak bir kaç commit mesajını bir mesajda birleştirmeyi sağlayabiliriz.