കോഴ്‌സ് വിദ്യാർത്ഥികൾക്കായി തയ്യാറാക്കിയ ലേഖനത്തിന്റെ പരിഭാഷ "ലിനക്സ് അഡ്മിനിസ്ട്രേറ്റർ".

മുമ്പ്, Linux-ൽ Hugepages എങ്ങനെ പരീക്ഷിക്കാമെന്നും പ്രവർത്തനക്ഷമമാക്കാമെന്നും ഞാൻ സംസാരിച്ചു.
നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഹ്യൂജ്‌പേജുകൾ ഉപയോഗിക്കാൻ ഒരു സ്ഥലമുണ്ടെങ്കിൽ മാത്രമേ ഈ ലേഖനം ഉപയോഗപ്രദമാകൂ. ഹ്യൂജ്‌പേജുകൾ ഉൽപ്പാദനക്ഷമതയെ മാന്ത്രികമായി മെച്ചപ്പെടുത്തുമെന്ന പ്രതീക്ഷയിൽ വഞ്ചിക്കപ്പെട്ട നിരവധി ആളുകളെ ഞാൻ കണ്ടുമുട്ടിയിട്ടുണ്ട്. എന്നിരുന്നാലും, വലിയപേജിംഗ് ഒരു സങ്കീർണ്ണമായ വിഷയമാണ്, തെറ്റായി ഉപയോഗിച്ചാൽ പ്രകടനത്തെ തരംതാഴ്ത്തിയേക്കാം.

ഭാഗം 1: ലിനക്സിൽ വലിയ പേജുകൾ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടോയെന്ന് പരിശോധിക്കുന്നു (ഒറിജിനൽ ഇവിടെ)

പ്രശ്നം:
നിങ്ങളുടെ സിസ്റ്റത്തിൽ HugePages പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടോയെന്ന് പരിശോധിക്കേണ്ടതുണ്ട്.

പരിഹാരം:
ഇത് വളരെ ലളിതമാണ്:

cat /sys/kernel/mm/transparent_hugepage/enabled

നിങ്ങൾക്ക് ഇതുപോലുള്ള എന്തെങ്കിലും ലഭിക്കും:

always [madvise] never

ലഭ്യമായ ഓപ്ഷനുകളുടെ ഒരു ലിസ്റ്റ് നിങ്ങൾ കാണും (എപ്പോഴും, ഭ്രാന്തൻ, ഒരിക്കലും), നിലവിൽ സജീവമായ ഓപ്‌ഷൻ പരാൻതീസിസിൽ ഉൾപ്പെടുത്തും (സ്ഥിരസ്ഥിതിയായി ഭ്രാന്തൻ).

ഭ്രാന്തൻ എന്നാണ് transparent hugepages സ്‌പഷ്‌ടമായി വലിയ പേജുകൾ അഭ്യർത്ഥിക്കുന്ന മെമ്മറി ഏരിയകൾക്കായി മാത്രം പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു ഭ്രാന്തൻ (2).

എല്ലായിപ്പോഴും എന്നാണ് transparent hugepages എല്ലാ പ്രക്രിയകൾക്കും എപ്പോഴും പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു. ഇത് സാധാരണയായി പ്രകടനം മെച്ചപ്പെടുത്തുന്നു, എന്നാൽ പല പ്രക്രിയകളും ചെറിയ അളവിൽ മെമ്മറി ഉപയോഗിക്കുന്ന ഒരു ഉപയോഗ സാഹചര്യം നിങ്ങൾക്കുണ്ടെങ്കിൽ, മൊത്തത്തിലുള്ള മെമ്മറി ലോഡ് ഗണ്യമായി വർദ്ധിക്കും.

ഒരിക്കലും എന്നാണ് transparent hugepages madvise ഉപയോഗിച്ച് ആവശ്യപ്പെടുമ്പോൾ പോലും ഉൾപ്പെടുത്തില്ല. കൂടുതൽ കണ്ടെത്താൻ, ബന്ധപ്പെടുക പ്രമാണീകരണം ലിനക്സ് കേർണലുകൾ.

ഡിഫോൾട്ട് മൂല്യം എങ്ങനെ മാറ്റാം

ഓപ്ഷൻ 1: നേരിട്ട് മാറ്റുക sysfs (റീബൂട്ട് ചെയ്ത ശേഷം പരാമീറ്റർ അതിന്റെ സ്ഥിര മൂല്യത്തിലേക്ക് മടങ്ങും):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

ഓപ്ഷൻ 2: പരിഷ്കരിച്ച കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് കേർണൽ വീണ്ടും കംപൈൽ ചെയ്ത് സിസ്റ്റം ഡിഫോൾട്ട് മാറ്റുക (നിങ്ങൾ ഒരു ഇഷ്‌ടാനുസൃത കേർണൽ ഉപയോഗിക്കുകയാണെങ്കിൽ മാത്രമേ ഈ ഓപ്ഷൻ ശുപാർശ ചെയ്യൂ):

• എല്ലായ്പ്പോഴും സ്ഥിരസ്ഥിതിയായി സജ്ജീകരിക്കാൻ, ഉപയോഗിക്കുക:

  CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

• madvise ഡിഫോൾട്ടായി സജ്ജീകരിക്കാൻ, ഉപയോഗിക്കുക:

  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

ഭാഗം 2: വലിയ പേജുകളുടെ ഗുണങ്ങളും ദോഷങ്ങളും

ഹ്യൂജ്‌പേജുകൾ ഉപയോഗിക്കുന്നതിന്റെ ഗുണങ്ങളും ദോഷങ്ങളും സാധ്യമായ പോരായ്മകളും തിരഞ്ഞെടുത്ത് വിശദീകരിക്കാൻ ഞങ്ങൾ ശ്രമിക്കും. ഹ്യൂജ്‌പേജുകൾ ഒരു പരിഭ്രാന്തി പരത്തുന്ന ആളുകൾക്ക് സാങ്കേതികമായി സങ്കീർണ്ണവും അനുചിതവുമായ ഒരു ലേഖനം മനസ്സിലാക്കാൻ പ്രയാസമായിരിക്കുമെന്നതിനാൽ, ലാളിത്യത്തിനായി ഞാൻ കൃത്യത ത്യജിക്കും. പല വിഷയങ്ങളും ശരിക്കും സങ്കീർണ്ണവും അതിനാൽ വളരെ ലളിതവുമാണെന്ന് ഓർമ്മിക്കേണ്ടതാണ്.

ലിനക്‌സിൽ പ്രവർത്തിക്കുന്ന 64-ബിറ്റ് x86 സിസ്റ്റങ്ങളെക്കുറിച്ചാണ് നമ്മൾ സംസാരിക്കുന്നത്, മിക്കവാറും എല്ലാ ആധുനിക ലിനക്സിലെയും പോലെ, സുതാര്യമായ വലിയ പേജുകളെ സിസ്റ്റം പിന്തുണയ്ക്കുന്നുവെന്ന് ഞാൻ അനുമാനിക്കുന്നു. പരിസ്ഥിതി.

താഴെയുള്ള ലിങ്കുകളിൽ കൂടുതൽ സാങ്കേതിക വിവരണം ഞാൻ അറ്റാച്ചുചെയ്യും.

വെർച്വൽ മെമ്മറി

നിങ്ങളൊരു C++ പ്രോഗ്രാമറാണെങ്കിൽ, മെമ്മറിയിലുള്ള ഒബ്‌ജക്റ്റുകൾക്ക് പ്രത്യേക വിലാസങ്ങൾ (പോയിന്റർ മൂല്യങ്ങൾ) ഉണ്ടെന്ന് നിങ്ങൾക്കറിയാം.

എന്നിരുന്നാലും, ഈ വിലാസങ്ങൾ മെമ്മറിയിലെ ഫിസിക്കൽ വിലാസങ്ങളെ പ്രതിഫലിപ്പിക്കണമെന്നില്ല (റാം വിലാസങ്ങൾ). അവർ വെർച്വൽ മെമ്മറിയിലെ വിലാസങ്ങളെ പ്രതിനിധീകരിക്കുന്നു. പ്രോസസറിന് ഒരു പ്രത്യേക MMU (മെമ്മറി മാനേജ്മെന്റ് യൂണിറ്റ്) മൊഡ്യൂൾ ഉണ്ട്, അത് കേർണലിനെ ഒരു ഫിസിക്കൽ ലൊക്കേഷനിലേക്ക് വെർച്വൽ മെമ്മറി മാപ്പ് ചെയ്യാൻ സഹായിക്കുന്നു.

ഈ സമീപനത്തിന് ധാരാളം ഗുണങ്ങളുണ്ട്, എന്നാൽ ഏറ്റവും പ്രധാനപ്പെട്ടവ ഇവയാണ്:

• പ്രകടനം (വിവിധ കാരണങ്ങളാൽ);
• പ്രോഗ്രാം ഒറ്റപ്പെടുത്തൽ, അതായത്, മറ്റൊരു പ്രോഗ്രാമിന്റെ മെമ്മറിയിൽ നിന്ന് ഒരു പ്രോഗ്രാമിനും വായിക്കാൻ കഴിയില്ല.

പേജുകൾ എന്താണ്?

വെർച്വൽ മെമ്മറി പേജുകളായി തിരിച്ചിരിക്കുന്നു. ഓരോ പേജും ഒരു നിർദ്ദിഷ്‌ട ഫിസിക്കൽ മെമ്മറിയിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു, അതിന് റാമിലെ ഒരു ഏരിയയിലേക്ക് ചൂണ്ടിക്കാണിക്കാൻ കഴിയും, അല്ലെങ്കിൽ ഒരു വീഡിയോ കാർഡ് പോലെയുള്ള ഒരു ഫിസിക്കൽ ഉപകരണത്തിലേക്ക് അസൈൻ ചെയ്‌തിരിക്കുന്ന വിലാസത്തിലേക്ക് ചൂണ്ടിക്കാണിക്കാൻ കഴിയും.

നിങ്ങൾ കൈകാര്യം ചെയ്യുന്ന മിക്ക പേജുകളും റാമിലേക്ക് പോയിന്റ് ചെയ്യുകയോ സ്വാപ്പ് ചെയ്യുകയോ ചെയ്യുന്നു, അതായത് അവ നിങ്ങളുടെ ഹാർഡ് ഡ്രൈവിലോ എസ്എസ്ഡിയിലോ സംഭരിച്ചിരിക്കുന്നു. ഓരോ പേജിന്റെയും ഫിസിക്കൽ ലേഔട്ട് കേർണൽ കൈകാര്യം ചെയ്യുന്നു. ഒരു കബളിപ്പിച്ച പേജ് ആക്‌സസ് ചെയ്‌താൽ, മെമ്മറി ആക്‌സസ് ചെയ്യാൻ ശ്രമിക്കുന്ന ത്രെഡ് കേർണൽ നിർത്തുന്നു, ഹാർഡ് ഡ്രൈവ്/എസ്‌എസ്‌ഡിയിൽ നിന്ന് പേജ് റാമിലേക്ക് റീഡ് ചെയ്യുന്നു, തുടർന്ന് ത്രെഡ് എക്‌സിക്യൂട്ട് ചെയ്യുന്നത് തുടരുന്നു.

ഈ പ്രക്രിയ സ്ട്രീം സുതാര്യമാണ്, അതായത് ഇത് HDD/SSD-യിൽ നിന്ന് നേരിട്ട് വായിക്കണമെന്നില്ല. സാധാരണ പേജുകളുടെ വലിപ്പം 4096 ബൈറ്റുകളാണ്. വലിയ പേജുകളുടെ വലുപ്പം 2 മെഗാബൈറ്റാണ്.

വിവർത്തന-അനുബന്ധ ബഫർ (TLB)

ഒരു പ്രോഗ്രാം മെമ്മറിയുടെ ഒരു പേജ് ആക്‌സസ് ചെയ്യുമ്പോൾ, ഏത് ഫിസിക്കൽ പേജിൽ നിന്നാണ് ഡാറ്റ വായിക്കേണ്ടതെന്ന് സിപിയു അറിഞ്ഞിരിക്കണം (അതായത്, ഒരു വെർച്വൽ വിലാസ മാപ്പ് ഉണ്ടായിരിക്കണം).

ഉപയോഗിക്കുന്ന പേജുകളെ കുറിച്ചുള്ള എല്ലാ വിവരങ്ങളും ഉൾക്കൊള്ളുന്ന ഒരു ഡാറ്റാ ഘടന (പേജ് ടേബിൾ) കേർണലിനുണ്ട്. ഈ ഡാറ്റ ഘടന ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ഒരു ഫിസിക്കൽ വിലാസത്തിലേക്ക് ഒരു വെർച്വൽ വിലാസം മാപ്പ് ചെയ്യാൻ കഴിയും.

എന്നിരുന്നാലും, പേജ് പട്ടിക വളരെ സങ്കീർണ്ണവും വേഗത കുറഞ്ഞതുമാണ്, അതിനാൽ ഒരു പ്രോസസ്സ് മെമ്മറി ആക്‌സസ് ചെയ്യുമ്പോഴെല്ലാം ഞങ്ങൾക്ക് മുഴുവൻ ഡാറ്റാ ഘടനയും വിശകലനം ചെയ്യാൻ കഴിയില്ല.

ഭാഗ്യവശാൽ, ഞങ്ങളുടെ പ്രോസസറിന് വെർച്വൽ, ഫിസിക്കൽ വിലാസങ്ങൾ തമ്മിലുള്ള മാപ്പിംഗ് കാഷെ ചെയ്യുന്ന ഒരു TLB ഉണ്ട്. ആദ്യ ആക്‌സസ് ശ്രമത്തിൽ തന്നെ പേജ് ടേബിൾ പാഴ്‌സ് ചെയ്യേണ്ടതുണ്ടെങ്കിലും, പേജിലേക്കുള്ള എല്ലാ തുടർന്നുള്ള ആക്‌സസുകളും TLB-യിൽ കൈകാര്യം ചെയ്യാനാകും, ഇത് വേഗത്തിലുള്ള പ്രവർത്തനത്തിന് അനുവദിക്കുന്നു.

ഒരു ഭൌതിക ഉപകരണമായി ഇത് നടപ്പിലാക്കിയതിനാൽ (ആദ്യം അത് വേഗത്തിലാക്കുന്നു), അതിന്റെ ശേഷി പരിമിതമാണ്. അതിനാൽ നിങ്ങൾക്ക് കൂടുതൽ പേജുകൾ ആക്‌സസ് ചെയ്യാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ, TLB-യ്‌ക്ക് അവയ്‌ക്കെല്ലാം മാപ്പിംഗ് സംഭരിക്കാൻ കഴിയില്ല, ഇത് നിങ്ങളുടെ പ്രോഗ്രാം വളരെ സാവധാനത്തിൽ പ്രവർത്തിക്കുന്നതിന് കാരണമാകുന്നു.

വലിയ പേജുകൾ രക്ഷയ്ക്കായി വരുന്നു

TLB ഓവർഫ്ലോ ഒഴിവാക്കാൻ നമുക്ക് എന്തുചെയ്യാൻ കഴിയും? (പ്രോഗ്രാമിന് ഇപ്പോഴും അതേ മെമ്മറി ആവശ്യമാണെന്ന് ഞങ്ങൾ കരുതുന്നു).

ഇവിടെയാണ് ഹ്യൂജ് പേജുകൾ വരുന്നത്. ഒരു TLB എൻട്രി മാത്രം ആവശ്യമുള്ള 4096 ബൈറ്റുകൾക്ക് പകരം, ഒരു TLB എൻട്രിക്ക് ഇപ്പോൾ 2 മെഗാബൈറ്റിലേക്ക് ചൂണ്ടിക്കാണിക്കാൻ കഴിയും. TLB-ക്ക് 512 എൻട്രികൾ ഉണ്ടെന്ന് നമുക്ക് അനുമാനിക്കാം, ഇവിടെ വലിയ പേജുകളില്ലാതെ നമുക്ക് പൊരുത്തപ്പെടുത്താനാകും:

4096 b⋅512=2 MB

അപ്പോൾ നമുക്ക് അവരുമായി എങ്ങനെ താരതമ്യം ചെയ്യാം:

2 MB⋅512=1 GB

ഇതുകൊണ്ടാണ് ഹ്യൂജ്‌പേജുകൾ ആകർഷണീയമായത്. അധികം പരിശ്രമിക്കാതെ തന്നെ ഉൽപ്പാദനക്ഷമത മെച്ചപ്പെടുത്താൻ അവർക്ക് കഴിയും. എന്നാൽ ഇവിടെ കാര്യമായ മുന്നറിയിപ്പുകളുണ്ട്.

വലിയ പേജുകൾ വഞ്ചന

ഓരോ മെമ്മറി പേജും എത്ര തവണ ഉപയോഗിക്കുന്നു എന്ന് കേർണൽ സ്വയമേവ നിരീക്ഷിക്കുന്നു. മതിയായ ഫിസിക്കൽ മെമ്മറി (റാം) ഇല്ലെങ്കിൽ, കൂടുതൽ പ്രധാനപ്പെട്ട പേജുകൾക്കായി കുറച്ച് റാം സ്വതന്ത്രമാക്കുന്നതിന് കേർണൽ ഹാർഡ് ഡിസ്കിലേക്ക് പ്രാധാന്യം കുറഞ്ഞ (കൂടുതൽ ഉപയോഗിക്കുന്ന) പേജുകൾ നീക്കും.
തത്വത്തിൽ, ഹ്യൂജ് പേജുകൾക്കും ഇത് ബാധകമാണ്. എന്നിരുന്നാലും, കേർണലിന് മുഴുവൻ പേജുകളും മാത്രമേ സ്വാപ്പ് ചെയ്യാനാകൂ, വ്യക്തിഗത ബൈറ്റുകൾ അല്ല.

ഞങ്ങൾക്ക് ഇതുപോലുള്ള ഒരു പ്രോഗ്രാം ഉണ്ടെന്ന് പറയാം:

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]); 

ഈ സാഹചര്യത്തിൽ, കേർണലിന് ഹാർഡ് ഡ്രൈവ്/എസ്എസ്ഡിയിൽ നിന്ന് 2 മെഗാബൈറ്റ് വിവരങ്ങൾ മാറ്റിസ്ഥാപിക്കേണ്ടതുണ്ട്. സാധാരണ പേജുകളെ സംബന്ധിച്ചിടത്തോളം, ഹാർഡ് ഡ്രൈവ്/എസ്എസ്ഡിയിൽ നിന്ന് 4096 ബൈറ്റുകൾ മാത്രമേ വായിക്കേണ്ടതുള്ളൂ.

അതിനാൽ, വലിയ പേജ് അസാധുവാക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് മുഴുവൻ പേജും ആക്സസ് ചെയ്യണമെങ്കിൽ മാത്രമേ അത് വേഗത്തിൽ വായിക്കൂ. ഇതിനർത്ഥം നിങ്ങൾ മെമ്മറിയുടെ വിവിധ ഭാഗങ്ങൾ ക്രമരഹിതമായി ആക്‌സസ് ചെയ്യാൻ ശ്രമിക്കുകയും കുറച്ച് കിലോബൈറ്റുകൾ വായിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, നിങ്ങൾ സാധാരണ പേജുകൾ ഉപയോഗിക്കണം, മറ്റൊന്നിനെക്കുറിച്ചും വിഷമിക്കേണ്ടതില്ല.

മറുവശത്ത്, നിങ്ങൾക്ക് മെമ്മറിയുടെ വലിയൊരു ഭാഗം ക്രമാനുഗതമായി ആക്സസ് ചെയ്യണമെങ്കിൽ, വലിയ പേജുകൾ നിങ്ങളുടെ പ്രകടനം മെച്ചപ്പെടുത്തും. എന്നിരുന്നാലും, നിങ്ങൾ ഇത് സ്വയം പരീക്ഷിക്കേണ്ടതുണ്ട് (അമൂർത്തമായ സോഫ്‌റ്റ്‌വെയർ ഉപയോഗിച്ചല്ല) കൂടാതെ എന്താണ് വേഗത്തിൽ പ്രവർത്തിക്കുന്നതെന്ന് കാണുക.

മെമ്മറിയിൽ അലോക്കേഷൻ

നിങ്ങൾ C എഴുതുകയാണെങ്കിൽ, ഹീപ്പിൽ നിന്ന് സ്വേച്ഛാപരമായ ചെറിയ (അല്ലെങ്കിൽ ഏകപക്ഷീയമായി വലിയ) മെമ്മറി അഭ്യർത്ഥിക്കാമെന്ന് നിങ്ങൾക്കറിയാം malloc(). നിങ്ങൾക്ക് 30 ബൈറ്റുകൾ മെമ്മറി ആവശ്യമാണെന്ന് പറയാം:

char* mymemory = malloc(30);

ഒരു പ്രോഗ്രാമർക്ക്, നിങ്ങൾ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ നിന്ന് 30 ബൈറ്റുകൾ മെമ്മറി "അഭ്യർത്ഥിക്കുന്നു" എന്ന് തോന്നുകയും ചില വെർച്വൽ മെമ്മറിയിലേക്ക് ഒരു പോയിന്റർ തിരികെ നൽകുകയും ചെയ്യുന്നു. എന്നാൽ യഥാർത്ഥത്തിൽ malloc () ഫംഗ്‌ഷനുള്ളിൽ നിന്ന് വിളിക്കുന്ന ഒരു സി ഫംഗ്‌ഷൻ മാത്രമാണ് brk, sbrk ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ നിന്ന് മെമ്മറി അഭ്യർത്ഥിക്കുക അല്ലെങ്കിൽ സ്വതന്ത്രമാക്കുക.

എന്നിരുന്നാലും, ഓരോ അലോക്കേഷനും കൂടുതൽ കൂടുതൽ മെമ്മറി അഭ്യർത്ഥിക്കുന്നത് കാര്യക്ഷമമല്ല; ചില മെമ്മറി സെഗ്‌മെന്റ് ഇതിനകം സ്വതന്ത്രമാക്കിയിരിക്കാനാണ് സാധ്യത (free()), നമുക്ക് അത് വീണ്ടും ഉപയോഗിക്കാം. malloc() സ്വതന്ത്ര മെമ്മറി പുനരുപയോഗിക്കുന്നതിന് വളരെ സങ്കീർണ്ണമായ അൽഗോരിതങ്ങൾ നടപ്പിലാക്കുന്നു.

അതേ സമയം, എല്ലാം നിങ്ങൾക്ക് ശ്രദ്ധിക്കപ്പെടാതെ സംഭവിക്കുന്നു, അതിനാൽ നിങ്ങളെ വിഷമിപ്പിക്കുന്നത് എന്തുകൊണ്ട്? എന്നാൽ വെല്ലുവിളി കാരണം free() എന്നല്ല അർത്ഥമാക്കുന്നത് മെമ്മറി നിർബന്ധമായും ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലേക്ക് ഉടൻ തിരികെ നൽകും.

മെമ്മറി ഫ്രാഗ്മെന്റേഷൻ എന്നൊരു സംഗതിയുണ്ട്. അങ്ങേയറ്റത്തെ സന്ദർഭങ്ങളിൽ, കുറച്ച് ബൈറ്റുകൾ മാത്രം ഉപയോഗിക്കുന്ന ഹീപ്പ് സെഗ്‌മെന്റുകൾ ഉണ്ട്, അതേസമയം അതിനിടയിലുള്ളതെല്ലാം സ്വതന്ത്രമാക്കിയിരിക്കുന്നു. (free()).

മെമ്മറി ഫ്രാഗ്മെന്റേഷൻ അവിശ്വസനീയമാംവിധം സങ്കീർണ്ണമായ വിഷയമാണെന്നും പ്രോഗ്രാമിലെ ചെറിയ മാറ്റങ്ങൾ പോലും കാര്യമായ സ്വാധീനം ചെലുത്തുമെന്നും ദയവായി ശ്രദ്ധിക്കുക. മിക്ക കേസുകളിലും, പ്രോഗ്രാമുകൾ കാര്യമായ മെമ്മറി വിഘടനത്തിന് കാരണമാകില്ല, പക്ഷേ കൂമ്പാരത്തിന്റെ ചില ഭാഗങ്ങളിൽ വിഘടിപ്പിക്കുന്നതിൽ ഒരു പ്രശ്നമുണ്ടെങ്കിൽ, വലിയ പേജുകൾ സ്ഥിതി കൂടുതൽ വഷളാക്കുമെന്ന് നിങ്ങൾ അറിഞ്ഞിരിക്കണം.

വലിയ പേജുകളുടെ തിരഞ്ഞെടുത്ത ഉപയോഗം

ഈ ലേഖനം വായിച്ചതിനുശേഷം, നിങ്ങളുടെ പ്രോഗ്രാമിന്റെ ഏതൊക്കെ ഭാഗങ്ങൾ ബൃഹത്തായ പേജുകൾ ഉപയോഗിക്കുന്നതിലൂടെ പ്രയോജനം നേടാമെന്നും ഏതെല്ലാം ചെയ്യാനാകില്ലെന്നും നിങ്ങൾ നിർണ്ണയിച്ചു. അപ്പോൾ വലിയ പേജുകൾ പ്രവർത്തനക്ഷമമാക്കേണ്ടതുണ്ടോ?

ഭാഗ്യവശാൽ നിങ്ങൾക്ക് ഉപയോഗിക്കാം madvise()അത് ഉപയോഗപ്രദമാകുന്ന മെമ്മറി ഏരിയകളിൽ മാത്രം വലിയ പേജിംഗ് പ്രവർത്തനക്ഷമമാക്കാൻ.

ആദ്യം, madvise() മോഡിൽ വലിയ പേജുകൾ പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുക നിർദ്ദേശങ്ങൾ ലേഖനത്തിന്റെ തുടക്കത്തിൽ.

പിന്നെ, ഉപയോഗിക്കുക madvise()വലിയപേജുകൾ എവിടെയാണ് ഉപയോഗിക്കേണ്ടതെന്ന് കൃത്യമായി കേർണലിനോട് പറയാൻ.

#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)

മെമ്മറി എങ്ങനെ കൈകാര്യം ചെയ്യാം എന്നതിനെക്കുറിച്ചുള്ള കേർണലിനുള്ള ഉപദേശമാണ് ഈ രീതി എന്നത് ശ്രദ്ധിക്കുക. തന്നിരിക്കുന്ന മെമ്മറിക്കായി കേർണൽ സ്വയമേവ ഭീമമായ പേജുകൾ ഉപയോഗിക്കുമെന്ന് ഇതിനർത്ഥമില്ല.

ഡോക്യുമെന്റേഷൻ റഫർ ചെയ്യുക (manpage)madviseമെമ്മറി മാനേജ്മെന്റിനെക്കുറിച്ചും കൂടുതലറിയാൻ madvise(), ഈ വിഷയത്തിന് അവിശ്വസനീയമാംവിധം കുത്തനെയുള്ള പഠന വക്രതയുണ്ട്. അതിനാൽ നിങ്ങൾ അതിൽ മികച്ച പ്രകടനം കാഴ്ചവയ്ക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, എന്തെങ്കിലും നല്ല ഫലങ്ങൾ പ്രതീക്ഷിക്കുന്നതിന് മുമ്പ് കുറച്ച് ആഴ്‌ചകൾ വായിക്കാനും പരിശോധിക്കാനും തയ്യാറാകുക.

എന്താണ് വായിക്കേണ്ടത്?

• വലിയ പേജുകളിൽ ഐബിഎം ഓപ്പൺസ്റ്റാക്ക് ലേഖനം
• സുതാര്യമായ വലിയ പേജുകൾ vs സുതാര്യമല്ലാത്ത വലിയ പേജുകൾ
• ടിഎൽബിയെക്കുറിച്ചുള്ള വിക്കിപീഡിയ ലേഖനം
• സുതാര്യമായ വലിയ പേജുകളിൽ ലിനക്സ് കേർണൽ ഡോക്യുമെന്റേഷൻ
• സ്റ്റാക്ക്ഓവർഫ്ലോ: വലിയ പേജുകൾ മെമ്മറി വിഘടനത്തിന് സാധ്യതയുണ്ട്
• വെർച്വൽ മെമ്മറി മാനേജ്‌മെന്റിനെക്കുറിച്ചുള്ള Microsoft ലേഖനം

ഒരു ചോദ്യമുണ്ടോ? അഭിപ്രായങ്ങളിൽ എഴുതുക!

അവലംബം: www.habr.com