Tenho tido esse problema há algum tempo e pensei que a nova versão do kernel Linux iria corrigi-lo, mas não foi o que aconteceu.
Não consigo descobrir qual é o erro, suspeito de algo relacionado à comparabilidade do BIOS, mas não consigo inicializar o Kali ou qualquer outro sistema operacional Linux nesse computador. Aqui estão as mensagens de erro geradas ao inicializar. (Cálculo: 83HM0001US)
Arquivos antigos do kernel estão se acumulando e eu gostaria de remover todos, exceto a versão atual e as duas versões anteriores, para liberar espaço.
Quando executo apt autoremove, os kernels antigos não são reconhecidos como elegíveis para remoção.
Então eu dei uma olhada /etc/apt/apt.conf.d/01autoremovee parece que todos linux-imageos pacotes são cobertos por NeverAutoRemoveo que explica por que eles não são pegos por apt autoremove. Aqui está o conteúdo:
APT
{
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image-[a-z0-9]*$";
"^linux-image-[a-z0-9]*-[a-z0-9]*$";
};
VersionedKernelPackages
{
# kernels
"linux-.*";
"kfreebsd-.*";
"gnumach-.*";
# (out-of-tree) modules
".*-modules";
".*-kernel";
};
Never-MarkAuto-Sections
{
"metapackages";
"contrib/metapackages";
"non-free/metapackages";
"restricted/metapackages";
"universe/metapackages";
"multiverse/metapackages";
};
Move-Autobit-Sections
{
"oldlibs";
"contrib/oldlibs";
"non-free/oldlibs";
"restricted/oldlibs";
"universe/oldlibs";
"multiverse/oldlibs";
};
};
Também vi que todas as imagens, cabeçalhos e módulos (usando Pop!_OS com um kernel Linux Surface ) são marcados como instalados manualmente com apt-mark showmanual | grep linux:
linux-headers-6.0.12-76060006
linux-headers-6.0.12-76060006-generic
linux-headers-6.0.6-76060006
linux-headers-6.1.11-76060111
linux-headers-6.1.11-76060111-generic
linux-headers-6.1.11-surface
linux-headers-6.1.12-surface
linux-headers-6.1.6-surface
linux-headers-6.2.0-76060200
linux-headers-6.2.0-76060200-generic
linux-headers-6.2.10-surface
linux-headers-6.2.14-surface
linux-headers-6.2.2-surface
linux-headers-6.2.5-surface
linux-headers-6.2.6-76060206
linux-headers-6.2.6-76060206-generic
linux-headers-6.2.8-surface
linux-headers-6.3.3-surface
linux-headers-6.3.7-surface
linux-headers-6.4.12-surface
linux-headers-6.4.2-surface
linux-headers-6.4.4-surface
linux-headers-6.4.6-76060406
linux-headers-6.4.6-76060406-generic
linux-headers-6.5.4-76060504
linux-headers-6.5.4-76060504-generic
linux-headers-6.5.5-surface
linux-headers-6.5.6-76060506
linux-headers-6.5.6-76060506-generic
linux-headers-6.5.6-surface
linux-headers-6.5.7-surface-2
linux-headers-6.6.1-surface-1
linux-headers-6.6.10-76060610
linux-headers-6.6.10-76060610-generic
linux-headers-6.6.11-surface-1
linux-headers-6.6.5-surface-1
linux-headers-6.6.6-76060606
linux-headers-6.6.6-76060606-generic
linux-headers-6.6.6-surface-1
linux-headers-6.7.2-surface-1
linux-headers-6.7.6-surface-1
linux-headers-6.7.9-surface-1
linux-headers-6.8.0-76060800daily20240311
linux-headers-6.8.0-76060800daily20240311-generic
linux-headers-6.8.1-surface-1
linux-headers-6.8.8-surface-1
linux-headers-6.9.3-76060903
linux-headers-6.9.3-76060903-generic
linux-headers-6.9.3-surface-2
linux-headers-surface
linux-image-6.1.11-surface
linux-image-6.1.12-surface
linux-image-6.1.6-surface
linux-image-6.2.0-76060200-generic
linux-image-6.2.10-surface
linux-image-6.2.14-surface
linux-image-6.2.2-surface
linux-image-6.2.5-surface
linux-image-6.2.6-76060206-generic
linux-image-6.2.8-surface
linux-image-6.3.3-surface
linux-image-6.3.7-surface
linux-image-6.4.12-surface
linux-image-6.4.2-surface
linux-image-6.4.4-surface
linux-image-6.4.6-76060406-generic
linux-image-6.5.4-76060504-generic
linux-image-6.5.5-surface
linux-image-6.5.6-76060506-generic
linux-image-6.5.6-surface
linux-image-6.5.7-surface-2
linux-image-6.6.1-surface-1
linux-image-6.6.10-76060610-generic
linux-image-6.6.11-surface-1
linux-image-6.6.5-surface-1
linux-image-6.6.6-76060606-generic
linux-image-6.6.6-surface-1
linux-image-6.7.2-surface-1
linux-image-6.7.6-surface-1
linux-image-6.7.9-surface-1
linux-image-6.8.0-76060800daily20240311-generic
linux-image-6.8.1-surface-1
linux-image-6.8.8-surface-1
linux-image-6.9.3-76060903-generic
linux-image-6.9.3-surface-2
linux-image-surface
linux-modules-6.0.12-76060006-generic
linux-modules-6.1.11-76060111-generic
linux-modules-6.2.0-76060200-generic
linux-modules-6.2.6-76060206-generic
linux-modules-6.4.6-76060406-generic
linux-modules-6.5.4-76060504-generic
linux-modules-6.5.6-76060506-generic
linux-modules-6.6.10-76060610-generic
linux-modules-6.6.6-76060606-generic
linux-modules-6.8.0-76060800daily20240311-generic
linux-modules-6.9.3-76060903-generic
Então tentei remover um dos pacotes mais antigos manualmente com apt remove linux-image-6.1.11-76060111-generic:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
linux-image-6.1.11-76060111-generic
0 upgraded, 0 newly installed, 1 to remove and 250 not upgraded.
After this operation, 12.3 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 1219145 files and directories currently installed.)
Removing linux-image-6.1.11-76060111-generic (6.1.11-76060111.202302091138~1675975749~22.04~f771a7f) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.11-76060111-generic
Isso deixa para trás os pacotes de cabeçalhos e módulos. Vejo que eles estão listados VersionedKernelPackagesna configuração autoremove, mas meu entendimento é que autoremove deve manter como padrão apenas as últimas versões.
A verificação das dependências dos cabeçalhos e módulos restantes mostra apenas uma dependência no linux-imagepacote removido com sucesso:
user@os:~$ apt-cache rdepends linux-headers-6.1.11-76060111-generic
linux-headers-6.1.11-76060111-generic
Reverse Depends:
linux-image-6.1.11-76060111-generic
user@os:~$ apt-cache rdepends linux-modules-6.1.11-76060111-generic
linux-modules-6.1.11-76060111-generic
Reverse Depends:
linux-image-6.1.11-76060111-generic
Que outros fatores podem estar desempenhando um papel na prevenção de que esses pacotes sejam removidos junto com o linux-imagepacote?
Pelo que entendi, um processo em tempo real significa que o processo obterá a CPU assim que precisar. O kernel é responsável por essa tarefa com seu mecanismo de agendamento interno.
Por outro lado, a afinidade de processo significa que o processo terá uma CPU dedicada para si mesmo e não será gerenciado pelo agendador do kernel. Então, se entendi corretamente, é ainda melhor do que ser um processo em tempo real. É como programar para um Arduino, mas apenas com uma CPU muito mais rápida. Além disso, no meu entendimento para afinidade de processo, precisamos de pelo menos uma CPU dual core e devemos deixar pelo menos uma CPU para o próprio sistema operacional. Então, com a ajuda da afinidade de processo, um programa que foi escrito para um Arduino pode ser portado para uma placa Linux como o Raspberry Pi Zero 2 W (que tem uma CPU quad-core) e teria todos os benefícios de um microcontrolador apenas com uma CPU mais rápida.
Meu entendimento está correto?
Estou tentando hackear o kernel do Linux e adicionar/modificar alguns arquivos de cabeçalho no formato include/linux. No entanto, quando eu gero o arquivo de patch usando diff:
diff -uprN -X linux/Documentation/dontdiff \
linux-5.15 linux-srctree > patch.p1
Encontro alterações em include/linuxnão incluídas em patch.p1. Em seguida, examino dontdiffo arquivo e encontro as seguintes linhas (em torno da linha 158), o que significa que ele exclui include/linuxdo arquivo de patch.
*lex.*.c
linux
logo_*.c
Então, por que dontdiffinclui linux? Como salvar alterações em arquivos de patch para cabeçalhos include/linux? Muito obrigado.
Estou investigando o impacto da memória ao conteinerizar dois processos que dependem do mesmo objeto compartilhado. Minha principal dúvida é se o objeto compartilhado será carregado na memória duas vezes ou não.
Essa pergunta já foi feita antes, mas as respostas não eram completas e contradiziam meus experimentos. Vou citar o que já encontrei:
Carregamento de bibliotecas compartilhadas e uso de RAM --> Use -fPIC para seu .so
Os contêineres docker compartilham RAM para arquivos mapeados na memória da mesma camada, mas de uma imagem diferente? --> Sim, mas depende da sua configuração. Você pode provar isso verificando o dispositivo e o id do inode do objeto compartilhado carregado. Nenhuma indicação de qual configuração usar.
https://stackoverflow.com/questions/35863608/shared-library-in-containers --> Sim, depende do seu driver de armazenamento. Os drivers de armazenamento aufs, overlay ou overlay2 oferecem suporte a isso.
https://stackoverflow.com/questions/63145223/about-loading-dynamic-library-in-container --> Cada contêiner é sua própria unidade de execução. Nenhum compartilhamento ocorre. Contradizendo com o anterior.
Usei a seguinte configuração:
Driver de armazenamento: Sobreposição
Abaixo você pode ver as informações de grep glib /proc/PID/maps. Os PIDs são os processos dos executáveis dentro do contêiner.
| /proc/17/maps:7efd3b630000-7efd41980000 | r-xp | 00000000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41980000-7efd41b7f000 | ---p | 06350000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b7f000-7efd41b80000 | r--p | 0634f000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b80000-7efd41b81000 | rw-p | 06350000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca97208000-7fca9d558000 | r-xp | 00000000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d558000-7fca9d757000 | ---p | 06350000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d757000-7fca9d758000 | r--p | 0634f000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d758000-7fca9d759000 | rw-p | 06350000 | 00:bb | 16802420 | /app/libglib.so |
Se eu interpretar o resultado corretamente, os dois processos visualizam arquivos completamente diferentes (o ID do dispositivo é diferente), portanto, o objeto compartilhado será carregado duas vezes na memória (parece consistente com o que vejo com o comando free).
De acordo com as informações que encontrei online, isso não deveria acontecer.
Tenho as seguintes perguntas:
Desde já, obrigado!
Não preciso de “ajuda” para inserir nouveauou instalar drivers proprietários. A questão é sobre nvidiafb. Obrigado.
Estou usando a GPU nvidia GT710 no Linux 6.9-rc2. Eu queria usar o nvidiafbdriver simples para minha GPU antiga. Nesse sistema, só preciso do framebuffer, nada mais (sem DRI). Mas nvidiafbnão funciona, trava.
# modprobe nvidiafb
Killed
#
nvidiafb: Device ID: 10de1287
Console: switching to colour dummy device 80x25
nvidiafb 0000:03:00.0: vgaarb: deactivate vga console
nvidiafb: CRTC0 analog not found
nvidiafb: CRTC1 analog not found
nvidiafb: Unable to detect display type...
...Using default of CRT
nvidiafb: Unable to detect which CRTCNumber...
...Defaulting to CRTCNumber 0
nvidiafb: Using CRT on CRTC 0
fbcon: NV28 (fb0) is primary device
divide error: 0000 [#1] PREEMPT_RT SMP
CPU: 0 PID: 194915 Comm: modprobe Tainted: G OE 6.9.0-rc2-home-rt+ #3 Hardware name: OEM X79G/X79G, BIOS 4.6.5 08/02/2022
RIP: 0010:nvGetClocks+0x18f/0x290 [nvidiafb]
Code: 0f 84 91 00 00 00 3d 30 03 00 00 0f 84 86 00 00 00 41 8b 89 04 05 00 00 0f b6 c5 44 0f b6 c9 c1 e9 10 0f af c2 31 d2 83 e1 0f <41> f7 f1 d3 e8 89 06 48 8b 87 a8 12 00 00 8b 88 00 05 00 00 0f b6
RSP: 0018:ffffa681b17e74e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff921541eb4518 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffa681b17e7520 RDI: ffff921541eb4420
RBP: ffffa681b17e74e8 R08: ffffa681b17e7524 R09: 0000000000000000 R10: ffff921541eb4420 R11: 00000000002e18c8 R12: 0000000000000020 R13: 0000000000000008 R14: 0000000000000008 R15: 0000000000000068
FS: 00007fa3af639c40(0000) GS:ffff922406200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f8401f000 CR3: 00000010275bc001 CR4: 00000000001706f0
Call Trace:
<TASK>
? show_regs+0x6b/0x80
? __die_body+0x24/0x70
? die+0x42/0x70
? do_trap+0xde/0x100
? do_error_trap+0x73/0xa0
? nvGetClocks+0x18f/0x290 [nvidiafb]
? exc_divide_error+0x3f/0x60
? nvGetClocks+0x18f/0x290 [nvidiafb]
? asm_exc_divide_error+0x1f/0x30
? nvGetClocks+0x18f/0x290 [nvidiafb]
NVCalcStateExt+0x1da/0x9b0 [nvidiafb]
? set_inverse_trans_unicode+0xd0/0x100
? kmalloc_trace+0xac/0x280
nvidiafb_set_par+0x4a3/0xa40 [nvidiafb]
fbcon_init+0x2af/0x600
visual_init+0xf2/0x190
do_bind_con_driver+0x1d2/0x4a0
do_take_over_console+0x144/0x240
? vprintk_default+0x21/0x30
do_fbcon_takeover+0x78/0x130
do_fb_registered+0x139/0x270
fbcon_fb_registered+0x3b/0x90
? fb_add_videomode+0x81/0xf0
register_framebuffer+0x20a/0x300
nvidiafb_probe+0x6a4/0xad0 [nvidiafb]
? rt_spin_unlock+0x1c/0x50
local_pci_probe+0x4f/0xb0
pci_device_probe+0xcc/0x280
really_probe+0xff/0x390
__driver_probe_device+0x8a/0x170
driver_probe_device+0x23/0xb0
__driver_attach+0xc9/0x190
? __pfx___driver_attach+0x10/0x10
bus_for_each_dev+0x80/0xd0
driver_attach+0x22/0x30
bus_add_driver+0x123/0x230
driver_register+0x68/0x130
? __pfx_nvidiafb_init+0x10/0x10 [nvidiafb]
__pci_register_driver+0x6e/0x80
nvidiafb_init+0x37/0x50 [nvidiafb]
do_one_initcall+0x4c/0x310
? do_init_module+0x28/0x270
? kmalloc_trace+0xac/0x280
do_init_module+0x6a/0x270
load_module+0x221b/0x22e0
init_module_from_file+0x9c/0xe0
? init_module_from_file+0x9c/0xe0
idempotent_init_module+0x173/0x230
__x64_sys_finit_module+0x61/0xc0
do_syscall_64+0x79/0x120
? ksys_mmap_pgoff+0x11c/0x260
? syscall_exit_to_user_mode+0x87/0x1c0
? do_syscall_64+0x85/0x120
? do_syscall_64+0x85/0x120
entry_SYSCALL_64_after_hwframe+0x71/0x79
RIP: 0033:0x7fa3af75988d
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe8864c978 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563b56dcbf80 RCX: 00007fa3af75988d RDX: 0000000000000000 RSI: 0000563b56dbacd2 RDI: 0000000000000005 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002 R10: 0000000000000005 R11: 0000000000000246 R12: 0000563b56dbacd2 R13: 0000563b56dcc1b0 R14: 0000563b56dcc950 R15: 0000563b56dc5110
</TASK> Modules linked in: nvidiafb(+) vgastate fb_ddc vmnet(OE) vmw_vsock_vmci_transport vsock vmw_vmci vmmon(OE) ip6t_REJECT nf_reject_ipv6 ip6t_rt ipt_REJECT nf_reject_ipv4 xt_recent nft_limit xt_limit xt_addrtype xt_tcpudp xt_pkttype nft_chain_nat xt_MASQUERADE xt_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink binfmt_misc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi nls_iso8859_1 snd_hda_intel snd_intel_dspcfg input_leds snd_intel_sdw_acpi kvm joydev snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq rapl snd_seq_device intel_cstate snd_timer serio_raw pcspkr snd ioatdma soundcore dca mac_hid sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy
async_pq async_xor async_tx raid1 raid0 gpu_sched drm_gpuvm drm_exec mxm_wmi video wmi i2c_algo_bit drm_ttm_helper ttm drm_display_helper cec rc_core drm_kms_helper cdc_ether usbnet drm hid_generic psmouse r8152 usbhid crct10dif_pclmul crc32_pclmul uas ghash_clmulni_intel sha512_ssse3 usb_storage hid sha256_ssse3 ahci sha1_ssse3 mii r8169 i2c_i801 libahci lpc_ich i2c_smbus realtek aesni_intel crypto_simd cryptd
---[ end trace 0000000000000000 ]---
RIP: 0010:nvGetClocks+0x18f/0x290 [nvidiafb]
Code: 0f 84 91 00 00 00 3d 30 03 00 00 0f 84 86 00 00 00 41 8b 89 04 05 00 00 0f b6 c5 44 0f b6 c9 c1 e9 10 0f af c2 31 d2 83 e1 0f <41> f7 f1 d3 e8 89 06 48 8b 87 a8 12 00 00 8b 88 00 05 00 00 0f b6
RSP: 0018:ffffa681b17e74e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff921541eb4518 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffa681b17e7520 RDI: ffff921541eb4420
RBP: ffffa681b17e74e8 R08: ffffa681b17e7524 R09: 0000000000000000
R10: ffff921541eb4420 R11: 00000000002e18c8 R12: 0000000000000020
R13: 0000000000000008 R14: 0000000000000008 R15: 0000000000000068
FS: 00007fa3af639c40(0000) GS:ffff922406200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f8401f000 CR3: 00000010275bc001 CR4: 00000000001706f0
note: modprobe[194915] exited with preempt_count 2
Qual é o problema exato que impede que ele funcione corretamente com minha GPU? A divisão em nvGetClocks+0x18f/0x290está em video/fbdev/nvidia/nv_hw.c, provavelmente aqui (linha 213) . Como a parte divisora da divisão acaba sendo zero, com esta GPU específica (não as outras, mais antigas)?
Obrigado.
Usar lshwpara consultar meu adaptador USB WiFi mostra o seguinte:
$ lshw -C network
*-network
description: Wireless interface
physical id: 12
bus info: usb@3:7
logical name: ...
serial: ...
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=rtw_8822bu driverversion=6.5.0-28-generic firmware=N/A ip=... link=yes multicast=yes wireless=IEEE 802.11
O adaptador funciona bem. No entanto, estou confuso com driver=rtw_8822bu. Até onde eu sei, não há nenhum modelo de kernel chamado rtw_8822bu.koem meu sistema; em vez disso, eu tenho rtw88_8822bu.ko,
/usr/lib/modules/6.5.0-28-generic/kernel/drivers/net/wireless/realtek/rtw88/rtw88_8822bu.ko
que também aparece usando lsmod:
$ lsmod | grep rtw
rtw88_8822bu 12288 0
rtw88_usb 24576 1 rtw88_8822bu
rtw88_8822b 229376 1 rtw88_8822bu
rtw88_core 356352 2 rtw88_usb,rtw88_8822b
mac80211 1720320 3 rtw88_core,rtw88_usb,rtl8xxxu
cfg80211 1323008 3 rtw88_core,mac80211,rtl8xxxu
Pergunta : Por que lshwaparece driver=rtw_8822buquando o módulo do kernel no sistema é nomeado rtw88_8822bu. De onde vem o nome anterior?
Ao tentar inicializar a partir de um NixOS live usb com 23.11, gnome para x86_64:
Em uma placa-mãe Asus C236 WSI com este BIOS:
$ ls -l /sys/class/dmi/id/bios*
-r--r--r-- 1 root root 4096 Apr 24 09:59 /sys/class/dmi/id/bios_date
-r--r--r-- 1 root root 4096 Apr 24 09:59 /sys/class/dmi/id/bios_release
-r--r--r-- 1 root root 4096 Apr 24 09:01 /sys/class/dmi/id/bios_vendor
-r--r--r-- 1 root root 4096 Apr 24 09:56 /sys/class/dmi/id/bios_version
$ cat /sys/class/dmi/id/bios*
10/21/2015
5.11
American Megatrends Inc.
P1.00
a tela de inicialização fica presa na primeira linha com:
Probing EDD (edd=off to disable)... ok
Na máquina virtual Kali, atribuí a memória 4G, assim;
Mas há um problema. Instalei o kernel de autoconstrução no convidado para hackear a memória.
# uname -a
Linux 15ud490-gx76k 6.8.4+ #8 SMP PREEMPT_DYNAMIC Sat Apt 6 15:49:20 KST 2024 x86_64 x86_64 x86_64 GNU/Linux
E quero ver uma área de fim de memória, digitada como abaixo.
Diz que o tamanho da memória é 16*0x336000 bytes. Então inferi o tamanho da memória com os resultados (no host).
$ python3
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 16*0x07fff0
8388352
>>> 16*0x07fff0/1024/1024
7.999755859375
>>> 16*0x335ff0/1024/1024
51.374755859375
>>> 16*0x336000/1024/1024
51.375
>>> 521000/1024/1024
0.49686431884765625
>>> (1024*1024*4+521000+3288)*1024/1024/1024/1024 # Convert into gigabytes
4.5
Dei a memória 4G para convidado mas ela tem 4,5GiB conforme acima. A troca é 1G, então é um absurdo.
Onde está a fonte de memória 0,5G ?????
Com base em minha pesquisa sobre mmap(), entendo que mmap usa paginação por demanda para copiar dados para o cache de páginas do kernel somente quando o endereço da memória virtual é tocado, por meio de falha de página.
Se estivermos lendo arquivos maiores que o cache da página, alguma página obsoleta no cache da página terá que ser trocada e recuperada. Portanto, minha pergunta é: a tabela de páginas será atualizada para mapear o endereço de memória virtual correspondente ao endereço da página antiga e obsoleta no cache (agora contendo novos dados)? Como isso acontece? Isso faz parte da chamada do sistema mmap()?