From owner-freebsd-current Mon Apr 23 21:51:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4404837B424; Mon, 23 Apr 2001 21:51:31 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3O4pV421689; Mon, 23 Apr 2001 21:51:31 -0700 (PDT) Date: Mon, 23 Apr 2001 21:51:31 -0700 From: Alfred Perlstein To: current@freebsd.org Cc: jhb@freebsd.org, jake@freebsd.org Subject: vm_mtx Message-ID: <20010423215131.D1790@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-all-your-base: are belong to us. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You can find the work I've done so far to make a giant vm mutex here: http://people.freebsd.org/~alfred/vm.diff It doesn't work (of course :)) it dies really early in the intialization when a vm_page is manipulated without the lock. It dies before it even gets to calibrating the clocks. I've been spending quite some time trying to get the higher level code to work and wanted to toss this diff out so that hopefully someone else (*nudge* John) might be able to get it further along. here's my "notes": requires vm_page_queues_mtx: manipulation of vm_page_queues vm_add_new_page() asserts vm_page_io_start/finish vm_page_wakeup vm_page_busy vm_page_flash vm_page_flag_clear vm_page_flag_set vm_page_cache vm_page_free vm_page_free_zero vm_object_page_clean mtx_assert(&vm_mtx, MA_OWNED); 283 vm_page_rename vm_page_insert vm_object_shadow <- lock held from vm_map_lookup() "vm_object.c" line 912 of 1 pmap_kenter needs to aquire some mutex on it's own because of its use in the zone allocator looks like zone allocator might have to recurse on vm_mtx, looks like zone allocator might have to go under vm_mtx or some trickery will be required when using zones as to avoid it vm_object_terminate vm_object_collapse zone allocator should probably do something like test the state of the vm lock, and lock it if not locked same for kmem_alloc/free holding vm_mtx over copyout? should we do it? probably not, but for small copyouts this can kill perf to lock/release need work: get/putpages routines need to lock vm_mtx pmaps spotted: pmap_copy_page pmap_page_protect pmap_resident_count pmap_enter pmap_pageable get the lock themselves if needed: pmap_kenter pmap_qenter pmap_qremove blist_destroy (calls free) blist_create (calls malloc M_WAITOK) prolly called from a safe spot exec_new_vmspace swap_pager_strategy done: unlock_map vm_map_lookup_done _vm_object_allocate (memcache candidate) blist_free pagedaemon_wakeup flushchainbuf with, switches to Giant getchainbuf without waitchainbuf with/without swap_pager_copy swap_pager_freespace swapout_procs (blocks) (holds locks over schedlock) swp_pager_freeswapspace swp_pager_meta_build requires swp_pager_meta_ctl requires swp_pager_meta_free requires swp_pager_meta_free_all requires swp_sizecheck vm_daemon vm_fault_additional_pages vm_freeze_copyopts (vm_pager_get_pages, pmap_copy_page) vm_map_entry_create (zalloc) vm_map_entry_delete vm_map_entry_dispose (calls zfree) vm_map_entry_link vm_map_entry_unlink vm_map_insert (pmap_object_init_pt) vm_map_lock* vm_map_lookup vm_map_lookup_entry vm_map_simplify_entry vm_map_unlock* vm_object_allocate (x: unlocks for zalloc) vm_object_backing_scan vm_object_coalesce vm_object_collapse (calls zfree) vm_object_deallocate vm_object_page_clean vm_object_page_remove vm_object_pip_wakeup vm_object_qcollapse vm_object_reference vm_object_shadow vm_object_terminate (blocks) (zfree) vm_object_vndeallocate (blocks) vm_page_activate vm_page_alloc vm_page_busy vm_page_copy (calls pmap_copy_page(), maybe unwind the lock?) vm_page_deactivate vm_page_dirty vm_page_flag_clear vm_page_flag_set vm_page_flash vm_page_free vm_page_free_zero vm_page_grab (blocks) vm_page_hold vm_page_insert vm_page_io_finish vm_page_io_start vm_page_list_find vm_page_lookup vm_page_protect vm_page_protect vm_page_protect (calls pmap_page_protect) vm_page_remove vm_page_rename vm_page_sleep_busy vm_page_undirty vm_page_unhold vm_page_unqueue vm_page_wakeup vm_page_zero_fill (calls pmap_zero_page(), maybe unwind the lock?) vm_pageout_map_deactivate_pages (pmap_resident_count,pmap_remove) vm_pageout_object_deactivate_pages (pmap_resident_count,pmap_ts_referenced,pmap_page_exists vm_pager_get_pages (probably blocks, must check getpages routines for pagers) vm_pager_page_unswapped (pager pgo_pageunswapped routine) vm_pager_has_page (calls pager pgo_haspage) vm_req_vmdaemon needs vm lock: vfs_buf_test_cache requires inmem requires vfs_vmio_release with, but releases! vfs_clean_pages with vm_hold_load_pages without, aquires vm_hold_free_pages with/without, aquires vfs_busy_pages without, aquires vfs_unbusy_pages without, aquires vfs_setdirty with/without, aquires bfreekva with/without, aquires brelse without, aquires bqrelse without, noaquire gbincore without, noaquire incore without, noaquire inmem without, aquires bufdone without, aquires geteblk doesn't lock check stats, needs lock? vmmeter.h: vm_page_count_severe vm_page_count_reserved vm_page_count_min vm_page_count_target vm_paging_target vm_paging_needed -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message