دیمن مدیریت حافظه

اندروید ۱۷ و بالاتر از دیمن مدیریت حافظه ( mmd ) پشتیبانی می‌کند، یک دیمن سیستمی که پیکربندی دیمن، تنظیمات قابل تنظیم و وظایف مداوم swap یا نگهداری ZRAM را مدیریت می‌کند.

پیشینه

قبل از معرفی mmd ، پیکربندی‌های ZRAM اندروید تکه‌تکه بودند و امکان سفارشی‌سازی محدودی را ارائه می‌دادند. mmd با متمرکز کردن مدیریت ZRAM، امکان منطق پیکربندی پیچیده‌تر و ساده‌سازی افزودن ویژگی‌های جدید و بهبودهای معماری، این مشکل را برطرف می‌کند. mmd همچنین تفکیک واضحی از نگرانی‌ها بین فرآیند system_server مبتنی بر جاوا و مدیریت swap یا حافظه در سطح هسته ایجاد می‌کند.

معماری و مدیریت ZRAM

پس از اتمام بوت (یعنی زمانی که sys.boot_completed=1 )، mmd_setup تلاش می‌کند تا ZRAM را با پارامترهای مشخص شده پیکربندی کند. پس از اتمام راه‌اندازی ZRAM، سیستم سرویس mmd را که وظایف تعمیر و نگهداری مداوم را انجام می‌دهد، فعال می‌کند.

با پروژه mmd ، عملیات نگهداری از system_server با ارسال درخواست‌های Binder به mmd با استفاده از رابط IMmd آغاز می‌شود. mmd وظایف نگهداری شامل انجام عملیات نوشتن مجدد، فشرده‌سازی مجدد و نوشتن مجدد در هر فرآیند ZRAM را بر اساس موتور سیاست داخلی خود انجام می‌دهد. هم زمان‌بندی از ActivityManagerService و هم سیاست‌های نگهداری ZRAM را می‌توان با استفاده از ویژگی‌های سیستم پیکربندی کرد.

یکپارچه‌سازی سرور سیستم (system_server)

فرآیند system_server مبتنی بر جاوا، زمان فراخوانی mmd را تعیین می‌کند. این فرآیند، پاکسازی‌های سراسری نگهداری را از بهینه‌سازی‌های هدفمند حافظه برای هر برنامه جدا می‌کند.

نگهداری عادی پس از پردازش

نگهداری سراسری ZRAM توسط ActivityManagerService با استفاده از com.android.server.memory.ZramMaintenance انجام می‌شود.

zram-maintenance

شکل 1. جریان زمان‌بندی نگهداری ZRAM.

  • موتور زمان‌بندی: ZramMaintenance یک کار پس‌زمینه دوره‌ای را با JobScheduler اندروید ثبت می‌کند.
  • محدودیت‌های کار: برای جلوگیری از وقفه‌های رابط کاربری پیش‌زمینه یا درگیری CPU، کار به صراحت با setRequiresDeviceIdle(true) و setRequiresBatteryNotLow(true) پیکربندی شده است.
  • فعال شدن Binder: وقتی زمان‌بند onStartJob() را اجرا می‌کند، system_server تابع mmd.doZramMaintenanceAsync() را فراخوانی می‌کند. این یک فراخوانی Binder ناهمزمان و یک طرفه است؛ system_server مانع از انتظار برای اتمام عملیات تعمیر و نگهداری نمی‌شود. mmd این را در یک thread worker پس‌زمینه در صف قرار می‌دهد تا فشرده‌سازی مجدد و نوشتن مجدد را به صورت متوالی انجام دهد.

نوشتن مجدد در هر فرآیند

تخلیه حافظه هدفمند به ازای هر فرآیند توسط ActivityManagerService با استفاده از com.android.server.am.CachedAppOptimizer مدیریت می‌شود.

mmd-writeback

شکل ۲. جریان بازنویسی mmd به ازای هر فرآیند

وقتی یک فرآیند به حالت ذخیره شده در پس‌زمینه منتقل می‌شود، ActivityManager فشرده‌سازی حافظه را انجام می‌دهد. اگر حذف حافظه کم فرآیند برای کاربر قابل مشاهده باشد، یعنی فرآیند میزبان یک Activity باشد، و اگر نوشتن مجدد ZRAM به ازای هر فرآیند، ردپای حافظه فرآیند را به نزدیک صفر برساند، سیستم این مراحل را دنبال می‌کند:

  1. پس از فشرده‌سازی، CachedAppOptimizer یک پیام با تأخیر ( ZRAM_WRITEBACK_MSG ) را به کنترل‌کننده‌ی فشرده‌سازی داخلی خود ارسال می‌کند (که توسط mZramWritebackWaitSeconds به تأخیر افتاده است).
  2. وقتی تأخیر به پایان برسد، ActivityManager یک توصیفگر فایل فرآیند امن به pidfd باز می‌کند.
  3. سرور سیستم، تابع mmd.asyncWritebackProcessZramMemory(pfd, callback) را فراخوانی می‌کند.
  4. mmd تابع ioctl برای نوشتن هر فرآیند را اجرا می‌کند و با استفاده از IMmdProcessWritebackCallback گزارش می‌دهد. در صورت موفقیت، ActivityManager رکورد فرآیند ( setIsZramWrittenBack(app, true) ) را علامت‌گذاری می‌کند تا oom_score_adj فرآیند را افزایش دهد و معیارها را در FrameworkStatsLog.ZRAM_WRITEBACK_EVENT ثبت کند.

پیش‌واکشی به ازای هر فرآیند

وقتی کاربری برنامه‌ای که قبلاً در حافظه پنهان (cache) ذخیره شده بود (و به دلیل UNFREEZE_REASON_ACTIVITY از حالت قفل خارج شده بود) را دوباره اجرا می‌کند، ActivityManager تأخیر راه‌اندازی برنامه ناشی از خطاهای عمده صفحه از حافظه پشتیبان را به حداقل می‌رساند:

  1. CachedAppOptimizer رویداد unfreeze را متوقف کرده و prefetchZram(app) را فراخوانی می‌کند.
  2. سرور سیستم، pidfd برنامه را با استفاده از mmd.asyncPrefetchProcessZramMemory(pfd) در Binder ارسال می‌کند. mmd تابع ioctl مربوط به ZRAM_ANDROID_IOC_PROCESS_PREFETCH را اجرا می‌کند که به هسته دستور می‌دهد صفحات مبادله شده را به صورت ناهمگام، در حالی که نخ رابط کاربری اصلی برنامه در حال مقداردهی اولیه است، به RAM بازگرداند.

مروری بر وظایف نگهداری و پس از پردازش

این بخش عملیات نگهداری پس‌زمینه و وظایف پس‌پردازشی را که mmd برای بهینه‌سازی فضای swap و حافظه سیستم اجرا می‌کند، شرح می‌دهد.

تعمیر و نگهداری در mmd

در mmd ، نگهداری به عملیات نگهداری زمان‌بندی‌شده و پس‌زمینه‌ای اشاره دارد که فضای swap و استفاده از حافظه فیزیکی را بدون تأثیر بر عملکرد پیش‌زمینه کاربر فعال بهینه می‌کند. به جای انجام عملیات‌های جابجایی مداوم و همزمان (که باعث بیدار شدن شدید CPU و اختلال در رابط کاربری می‌شود)، نگهداری به صورت غیرهمزمان انجام می‌شود:

  1. system_server به صورت دوره‌ای تابع doZramMaintenanceAsync() را در سراسر Binder اجرا می‌کند.

  2. mmd درخواست را در صف کار پس‌زمینه LowPrioWorkItem::ZramMaintenance قرار می‌دهد.

  3. یک نخ کارگر واحد در mmd وجود دارد که هم صف با اولویت بالا و هم صف با اولویت پایین را مدیریت می‌کند. اقلام کاری با اولویت بالا (مانند پیش‌واکشی هر فرآیند) ابتدا پردازش می‌شوند و می‌توانند اقلام کاری با اولویت پایین را قبضه کنند. نگهداری و نوشتن مجدد هر فرآیند به عنوان اقلام کاری با اولویت پایین عمل می‌کنند. وقتی باز می‌شود، نخ کارگر دو عملیات نگهداری اولیه را به ترتیب اجرا می‌کند:

    • فشرده‌سازی مجدد ZRAM: صفحات swap موجود را بررسی کرده و صفحات بیکار را با استفاده از یک الگوریتم فشرده‌سازی ثانویه با نسبت بالاتر، مثلاً zstd ، دوباره فشرده می‌کند.

    • بازنویسی ZRAM: صفحات بیکار را اسکن می‌کند و آنها را به طور کامل از RAM به حافظه فلش پشتیبان، یک دستگاه حلقه‌ای از فایلی در /data منتقل می‌کند.

وظایف پس از پردازش در ZRAM

در ماژول ZRAM هسته لینوکس و معماری mmd ، وظایف پس‌پردازشی، تبدیل‌های ناهمزمانی هستند که پس از تعویض صفحات حافظه توسط مسیرهای بازیابی استاندارد هسته (kswapd یا فشرده‌سازی) روی آنها اعمال می‌شوند.

وقتی یک صفحه در ابتدا تعویض می‌شود، سیستم سرعت را در اولویت قرار می‌دهد: از یک الگوریتم فشرده‌سازی اولیه سریع (مانند lz4 ) استفاده می‌کند و صفحه فشرده‌شده را در RAM ذخیره می‌کند. با این حال، با گذشت زمان، بسیاری از صفحات تعویض‌شده سرد یا غیرفعال می‌شوند، به عنوان مثال، برنامه‌های ذخیره‌شده در پس‌زمینه که ساعت‌ها از سر گرفته نمی‌شوند. رها کردن صفحات سرد در ZRAM سریع و با فشرده‌سازی کم، ناکارآمد است.

خط لوله پس از پردازش

mmd یک چرخه حیات پساپردازش چند مرحله‌ای را برای بهینه‌سازی این صفحات پیاده‌سازی می‌کند:

mmd-page-lifecycle

شکل ۳. چرخه حیات صفحه mmd .

  1. مرحله ۱: جابجایی اولیه (فشرده‌سازی سریع): ابتدا حافظه از طریق kswapd یا فشرده‌سازی برنامه بازیابی می‌شود. معمولاً این بازیابی اولیه با استفاده از یک الگوریتم فشرده‌سازی سریع مانند lz4 انجام می‌شود و محتویات در RAM ذخیره می‌شوند.

  2. مرحله ۲: علامت‌گذاری حالت سکون (پیری و ردیابی): قابلیت ردیابی حالت سکون mmd به ردیابی حافظه هسته ( CONFIG_ZRAM_TRACK_ENTRY_ACTIME ) دسترسی پیدا می‌کند یا از نشانگر حالت سکون نرم‌افزاری خود برای ردیابی مدت زمان دست‌نخورده ماندن صفحات استفاده می‌کند.

  3. مرحله ۳: پس‌پردازش ۱ - فشرده‌سازی مجدد (احیای درون حافظه) : صفحاتی که به سن بیکاری فشرده‌سازی مجدد می‌رسند ( min_idle_seconds تا max_idle_seconds ) تحت فشرده‌سازی مجدد قرار می‌گیرند. mmd در /sys/block/zram0/recompress تا به هسته دستور دهد صفحه lz4 را از حالت فشرده خارج کرده و با استفاده از zstd آن را دوباره فشرده کند. این کار رم فیزیکی را بدون ایجاد فرسایش در نوشتن فلش، بازیابی می‌کند.

  4. مرحله ۴: پس‌پردازش ۲ - نوشتن مجدد (انتقال به حافظه فلش): اگر فشار حافظه ادامه یابد و صفحات به سن بیکاری نوشتن مجدد (معمولاً ۲۰ ساعت یا بیشتر) برسند، mmd نوشتن مجدد را آغاز می‌کند. mmd در /sys/block/zram0/idle و /sys/block/zram0/writeback می‌نویسد تا صفحه فشرده‌شده را به‌طور کامل از RAM به حافظه فلش پشتیبان منتقل کند.

پیکربندی تنظیمات ZRAM

mmd ویژگی‌های تنظیم ZRAM زیر را بارگذاری و پردازش می‌کند:

ملک استفاده کنید پیش‌فرض
mmd.zram.enabled آیا تنظیم ZRAM mmd فعال است یا خیر. false
mmd.zram.num_devices تعداد دستگاه‌های ZRAM برای پیکربندی. برای تعداد N ، دستگاه‌های zram0 تا zram<N-1> باید قبل از اینکه سیستم sys.boot_completed=1 را تنظیم کند، وجود داشته باشند. ویژگی‌های موجود در لیست دستگاه‌های هر ZRAM را می‌توان بر اساس هر دستگاه پیکربندی کرد. 1
mmd.zram.device_priority مقادیر اولویت‌دار برای انتقال هنگام فراخوانی swapon . تنظیم نشده
mmd.zram.comp_algorithm الگوریتم فشرده‌سازی ZRAM. در صورت عدم تعیین الگوریتم فشرده‌سازی پیش‌فرض هسته، از آن استفاده می‌شود. تنظیم نشده
mmd.zram.size اندازه دستگاه ZRAM بر حسب بایت، یا درصدی از اندازه رم دستگاه، مثلاً 75% . 50%
mmd.zram.writeback.enabled آیا قابلیت نوشتن مجدد ZRAM فعال شود یا خیر. false
mmd.zram.writeback.device_size اندازه دستگاه writeback بر حسب بایت یا درصد پارتیشن داده. اندازه واقعی دستگاه را می‌توان بر اساس فضای موجود در پارتیشن داده تنظیم کرد. 1073741824 (۱ گیگابایت)
mmd.zram.writeback.min_free_space_mib حداقل فضای خالی بر حسب مگابایت که باید پس از راه‌اندازی دستگاه رایت‌بک در دسترس باشد. 1536 (۱.۵ گیگابایت)
mmd.zram.writeback.use_nr_tags_prop وقتی true ، از مقدار mmd.zram.writeback.nr_tags برای پیکربندی عمق صف دستگاه حلقه‌ای پشتیبان نوشتن ZRAM استفاده می‌کند. این یک راه حل برای موقعیت‌هایی است که نمی‌توان سیاست SELinux فروشنده را طوری پیکربندی کرد که به mmd اجازه دهد مستقیماً nr_tags دستگاه بلوک پشتیبان /data بخواند. false
mmd.zram.writeback.nr_tags به mmd.zram.writeback.use_nr_tags_prop مراجعه کنید. تنظیم نشده
mmd.zram.recompression.enabled آیا قابلیت فشرده‌سازی مجدد ZRAM فعال شود یا خیر. false
mmd.zram.recompression.algorithm الگوریتم فشرده‌سازی مجدد ZRAM ثانویه. zstd

ویژگی‌های دستگاه Per-ZRAM

وقتی mmd.zram.num_devices بزرگتر از یک باشد، می‌توان به صورت اختیاری ویژگی‌های خاص را بر اساس هر دستگاه ZRAM پیکربندی کرد، به این صورت که این ویژگی را روی مقداری که با کاما از هم جدا شده و دقیقاً شامل عناصر mmd.zram.num_devices است، تنظیم کرد. این ویژگی‌ها عبارتند از:

  • mmd.zram.size
  • mmd.zram.comp_algorithm
  • mmd.zram.device_priority
  • mmd.zram.recompression.enabled
  • mmd.zram.recompression.huge_idle.enabled
  • mmd.zram.recompression.idle.enabled
  • mmd.zram.recompression.huge.enabled
  • mmd.zram.recompression.threshold_bytes
  • mmd.zram.recompression.algorithm
  • mmd.zram.writeback.device_size
  • mmd.zram.writeback.huge_idle.enabled
  • mmd.zram.writeback.idle.enabled
  • mmd.zram.writeback.huge.enabled

منسوخ شدن تنظیمات ZRAM فعلی

اگرچه swapon_all هنوز در اندروید برای تنظیم ZRAM و فضای swap مبتنی بر دیسک موجود است، mmd رویکرد ترجیحی برای مدیریت ZRAM به دلیل پیکربندی آسان‌تر و ویژگی‌های پیشرفته‌ای مانند فشرده‌سازی مجدد ZRAM است.

وقتی تنظیم mmd ZRAM توسط mmd.zram.enabled فعال می‌شود:

  • راه‌اندازی ZRAM در پیاده‌سازی swapon_all دیگر امکان‌پذیر نیست.
  • پیکربندی‌های موجود ZRAM مانند config_zramWriteback در فایل config.xml و ویژگی‌های سیستم writeback مربوط به ro.zram.* نادیده گرفته می‌شوند.

تنظیمات تعمیر و نگهداری ZRAM

نگهداری ZRAM باید به صورت پیش‌فرض کار کند و شما می‌توانید با استفاده از ویژگی‌های سیستم در این بخش، آن را دقیق‌تر تنظیم کنید.

برنامه‌ریزی تعمیر و نگهداری ZRAM

این ویژگی‌ها نحوه و زمان برنامه‌ریزی وظایف نگهداری ZRAM توسط system_server را کنترل می‌کنند.

ملک استفاده کنید پیش‌فرض
mm.zram.maintenance.first_delay_seconds تأخیر قبل از شروع اولین تعمیر و نگهداری ZRAM. 3600 (۱ ساعت)
mm.zram.maintenance.periodic_delay_seconds تأخیر بین برنامه‌ریزی‌های بعدی تعمیر و نگهداری ZRAM. 3600 (۱ ساعت)
mm.zram.maintenance.require_device_idle آیا فقط زمانی که دستگاه بیکار است، تعمیر و نگهداری ZRAM آغاز شود؟ true
mm.zram.maintenance.require_battery_not_low اینکه آیا قبل از شروع تعمیر و نگهداری ZRAM، نیاز به باتری کم نباشد یا خیر. true

سیاست بازخوانی ZRAM

پارامترهای زیر زمان و نوع حافظه‌ای که روی دستگاه پشتیبان نوشته می‌شود را کنترل می‌کنند:

ملک استفاده کنید پیش‌فرض
mmd.zram.writeback.backoff_seconds زمان خاموشی از آخرین عملیات نوشتن مجدد. 600 (۱۰ دقیقه)
mmd.zram.writeback.min_idle_seconds همراه با mmd.zram.writeback.max_idle_seconds برای محاسبه‌ی مدت زمان بیکاری یک صفحه که واجد شرایط نوشتن مجدد بر اساس کسر استفاده از حافظه است. مدت زمان بیکاری محاسبه‌شده به صورت نمایی بین دو پارامتر درون‌یابی می‌شود تا کار را به حداقل برساند، در حالی که تحت فشار حافظه نباشد. 72000 (۲۰ ساعت)
mmd.zram.writeback.max_idle_seconds حداکثر ثانیه‌های مورد استفاده برای محاسبه‌ی پویای عمر صفحه‌ی غیرفعال بر اساس میزان استفاده از حافظه. 90000 (۲۵ ساعت)
mmd.zram.writeback.huge.enabled آیا نوشتن مجدد صفحه HUGE فعال شود یا خیر. false
mmd.zram.writeback.idle.enabled آیا نوشتن مجدد صفحه IDLE فعال شود یا خیر. true
mmd.zram.writeback.huge_idle.enabled آیا نوشتن مجدد صفحه HUGE_IDLE فعال شود یا خیر. true
mmd.zram.writeback.min_bytes حداقل بایت‌های لازم برای نوشتن مجدد در یک دور از نوشتن مجدد در حالت بیکاری. 5242880 (۵ مگابایت)
mmd.zram.writeback.max_bytes حداکثر بایت‌هایی که می‌توان در یک دور از نوشتن در حالت بیکاری، دوباره نوشت. 314572800 (۳۰۰ مگابایت)
mmd.zram.writeback.max_bytes_per_day حداکثر بایت‌هایی که می‌توان در یک دوره ۲۴ ساعته دوباره نوشت. 25769803776 (۲۴ گیگابایت)
mmd.zram.writeback.limit.enabled آیا حسابداری محدودیت بودجه‌ی بازپرداخت روزانه فعال شود یا خیر. true

سیاست فشرده‌سازی مجدد ZRAM

پارامترهای زیر زمان و نوع حافظه‌ای که دوباره فشرده می‌شود را کنترل می‌کنند:

ملک استفاده کنید پیش‌فرض
mmd.zram.recompression.backoff_seconds زمان برگشت از آخرین فشرده‌سازی مجدد. 1800 (۳۰ دقیقه)
mmd.zram.recompression.min_idle_seconds همراه با mmd.zram.recompression.max_idle_seconds برای محاسبه‌ی مدت زمان بیکاری یک صفحه که واجد شرایط فشرده‌سازی مجدد بر اساس کسر استفاده از حافظه است. مدت زمان بیکاری محاسبه‌شده به صورت نمایی بین دو پارامتر درون‌یابی می‌شود تا کار را به حداقل برساند، در حالی که تحت فشار حافظه نباشد. 7200 (۲ ساعت)
mmd.zram.recompression.max_idle_seconds حداکثر ثانیه مورد استفاده برای محاسبه پویای سن صفحه غیرفعال. 14400 (۴ ساعت)
mmd.zram.recompression.threshold_bytes حداقل اندازه صفحات ZRAM بر حسب بایت که برای فشرده‌سازی مجدد در نظر گرفته شده است. 1024 (۱ کیلوبایت)
mmd.zram.recompression.huge.enabled آیا فشرده‌سازی مجدد صفحه HUGE فعال شود یا خیر. true
mmd.zram.recompression.idle.enabled آیا فشرده‌سازی مجدد صفحه IDLE فعال شود یا خیر. true
mmd.zram.recompression.huge_idle.enabled فعال کردن فشرده‌سازی مجدد صفحه HUGE_IDLE . true

ردیابی صفحات غیرفعال ZRAM

قابلیت نگهداری ZRAM mmd ، صفحات ZRAM را بر اساس مدت زمان آخرین دسترسی به آنها، به عنوان صفحات غیرفعال علامت‌گذاری می‌کند. این ویژگی مستلزم فعال بودن پیکربندی‌های هسته CONFIG_ZRAM_TRACK_ENTRY_ACTIME یا CONFIG_ZRAM_MEMORY_TRACKING است. CONFIG_ZRAM_TRACK_ENTRY_ACTIME به طور پیش‌فرض در هسته‌های GKI نسخه ۶.۱۸ و بالاتر فعال است. در هسته‌های قدیمی‌تر، این قابلیت سربار حافظه دارد و به طور پیش‌فرض فعال نیست.

اگر پیکربندی هسته فعال نباشد، نگهداری ZRAM mmd به یک منطق جایگزین نرم‌افزاری برای ردیابی صفحات بیکار ZRAM برمی‌گردد:

  1. هنگام شروع mmd تمام صفحات ZRAM را به عنوان بیکار علامت‌گذاری کنید.

  2. تا زمانی که دوره‌ی بک‌آف مورد نیاز سپری نشده است، از انجام تعمیرات بعدی ZRAM صرف نظر کنید.

  3. صفحات بیکار ZRAM را بازنویسی یا دوباره فشرده کنید. اگر به دلیل محدودیت‌های بازنویسی، صفحات بیکار باقی مانده باشند، mmd در تعمیر و نگهداری بعدی بدون علامت‌گذاری صفحات جدید به عنوان بیکار، به نوشتن صفحات قبلی ادامه می‌دهد (از مرحله ۴ صرف نظر کنید).

  4. اگر تمام صفحات بیکار دوباره نوشته شدند، تمام صفحات ZRAM را دوباره به عنوان بیکار علامت‌گذاری کنید و به مرحله ۲ برگردید. اگر نوشتن مجدد ZRAM غیرفعال باشد، mmd تمام صفحات ZRAM را پس از مدت زمان بیکاری فشرده‌سازی مجدد، به عنوان بیکار علامت‌گذاری می‌کند.

راهنمای عیب‌یابی و اعتبارسنجی

برای تأیید و تشخیص عملکرد mmd و ZRAM از مراحل اعتبارسنجی و رویه‌های عیب‌یابی زیر استفاده کنید.

اعتبارسنجی تنظیمات ZRAM

برای تأیید اینکه mmd با موفقیت ZRAM را در هنگام بوت پیکربندی کرده است:

  1. الگوریتم فشرده‌سازی فعال و اندازه دیسک را بررسی کنید:

    cat /sys/block/zram0/comp_algorithm
cat /sys/block/zram0/disksize

  2. بررسی ویژگی‌های سیستم mmd و وضعیت سرویس در حال اجرا:

    getprop | grep mmd.zram
dumpsys -l | grep mmd

اعتبارسنجی نگهداری و نوشتن مجدد ZRAM

تأیید کنید که وظایف بازیابی اطلاعات و فشرده‌سازی مجدد ZRAM به درستی کار می‌کنند:

  1. وضعیت دستگاه بلوک پشتیبان را بررسی کنید:

    cat /sys/block/zram0/bd_stat

  2. با نظارت بر /sys/block/zram0/mm_stat ، کارایی فشرده‌سازی مجدد را بررسی کنید. تغییرات در اندازه داده‌های فشرده‌شده باید پس از چرخه‌های نگهداری ظاهر شوند.

اعتبارسنجی نوشتن مجدد به ازای هر فرآیند

برای تأیید صحت عملکرد نوشتن در هر فرآیند، می‌توان از موارد زیر استفاده کرد:

  • برای مشاهده‌ی لاگ‌های موفقیت‌آمیز نوشتن مجدد یا تشخیص خطا، adb logcat -s mmd را بررسی کنید.

مشکلات رایج و تشخیص

موارد زیر موقعیت‌های خطای رایجی هستند که ممکن است کاربر با آنها مواجه شود:

  • WritebackDailyLimitExceeded : این خطا نشان می‌دهد که سهمیه mmd.zram.writeback.max_bytes_per_day به پایان رسیده است. وقتی این اتفاق می‌افتد، mmd نوشتن در حالت idle را تا زمان رسیدن به بازه زمانی ۲۴ ساعته متوقف می‌کند.
  • Process prefetch or writeback failed : این خطا می‌تواند در logcat مشاهده شود زمانی که یک ioctl با شکست مواجه می‌شود. علل رایج عبارتند از:
    • EBADF یا ESRCH : فرآیند هدف قبل از اینکه mmd بتواند pidfd را به هسته ارسال کند، پایان یافت.
    • ENOSPC : پارتیشن ذخیره‌سازی پشتیبان پر است، یا صف دستگاه حلقه به پایان رسیده است.
  • ZRAM تنظیم نشده است: اگر mmd در هنگام بوت شدن نتواند ZRAM را پیکربندی کند، ممکن است به این دلیل باشد که swapon_all قدیمی یا اسکریپت‌های init فروشنده، فایل /dev/block/zram0 را قبل از اینکه mmd بتواند اجرا شود، قفل کرده‌اند.